Skip to main content

Tree Engineering for Bit Index Explicit Replication (BIER-TE)
draft-ietf-bier-te-arch-13

Revision differences

Document history

Date Rev. By Action
2022-10-11
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-07-11
13 (System) RFC Editor state changed to AUTH48
2022-06-15
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-04-28
13 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2022-04-28
13 Tero Kivinen Assignment of request for Last Call review by SECDIR to Stefan Santesson was marked no-response
2022-04-26
13 (System) RFC Editor state changed to EDIT
2022-04-26
13 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-04-26
13 (System) Announcement was received by RFC Editor
2022-04-26
13 (System) IANA Action state changed to No IANA Actions from In Progress
2022-04-26
13 (System) IANA Action state changed to In Progress
2022-04-26
13 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-04-26
13 Cindy Morgan IESG has approved the document
2022-04-26
13 Cindy Morgan Closed "Approve" ballot
2022-04-26
13 Alvaro Retana IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2022-04-26
13 Alvaro Retana Ballot approval text was generated
2022-04-25
13 (System) Removed all action holders (IESG state changed)
2022-04-25
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-04-25
13 Toerless Eckert New version available: draft-ietf-bier-te-arch-13.txt
2022-04-25
13 Toerless Eckert New version accepted (logged-in submitter: Toerless Eckert)
2022-04-25
13 Toerless Eckert Uploaded new revision
2022-03-10
12 (System) Changed action holders to Toerless Eckert, Michael Menth, Gregory Cauchie (IESG state changed)
2022-03-10
12 Alvaro Retana IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup
2022-03-10
12 (System) Removed all action holders (IESG state changed)
2022-03-10
12 Alvaro Retana IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup
2022-02-22
12 Benjamin Kaduk
[Ballot comment]
Thanks for the updates to address my Discuss and Comment points!

Just a handful of nits I spotted when reviewing the diff from …
[Ballot comment]
Thanks for the updates to address my Discuss and Comment points!

Just a handful of nits I spotted when reviewing the diff from -10 to -12:


Section 2.3

      2.  In BIER, the implied reference option for the core part of
          the BIER layer control plane are the BIER extensions for
          distributed routing protocols.  This includes ISIS/OSPF
          extensions for BIER, [RFC8401] and [RFC8444].

nit: s/option/options/

Section 4.1

  In BIER, each BIFT rows also requires a "Forwarding Bit Mask" (F-BM)

nit: s/rows/row/

Section 5.1.3

Many thanks for the additional discussion here; it really helps me
understand the intent!

  However, if the bit position is shared across leaf-BFER, and packets
  are therefore decapsulated potentially unnecessarily, this may still
  be appropriate if the decapsulated payload of the BIER-TE packet does
  indicate whether or not the packet needs to be further processed/
  received.  [...]

nit: I would s/does indicate/indicates/ -- my brain is prompted to
autocomplete "does" to "does not", since the "does indicate" construction
is somewhat unusual and typically only used in situations where a
particular emphasis is desired, often in contrast to an alternate
scenario.

Section 5.1.7

  An ECMP() adjacency allows to use just one BP to deliver packets to
  one one of N adjacencies instead of one BP for each adjacency.  In

nit: s/one one/one/
2022-02-22
12 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2022-02-03
12 Bernie Volz Closed request for Telechat review by INTDIR with state 'Overtaken by Events'
2022-02-03
12 Bernie Volz Closed request for Telechat review by INTDIR with state 'Overtaken by Events'
2022-01-28
12 Toerless Eckert New version available: draft-ietf-bier-te-arch-12.txt
2022-01-28
12 (System) New version accepted (logged-in submitter: Toerless Eckert)
2022-01-28
12 Toerless Eckert Uploaded new revision
2021-11-15
11 (System) Changed action holders to Alvaro Retana (IESG state changed)
2021-11-15
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-11-15
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-11-15
11 Toerless Eckert New version available: draft-ietf-bier-te-arch-11.txt
2021-11-15
11 (System) New version accepted (logged-in submitter: Toerless Eckert)
2021-11-15
11 Toerless Eckert Uploaded new revision
2021-10-13
10 Carlos Jesús Bernardos Assignment of request for Telechat review by INTDIR to Suzanne Woolf was marked no-response
2021-10-13
10 Carlos Jesús Bernardos Assignment of request for Telechat review by INTDIR to Juan-Carlos Zúñiga was marked no-response
2021-08-26
10 (System) Changed action holders to Toerless Eckert, Michael Menth, Gregory Cauchie, Alvaro Retana (IESG state changed)
2021-08-26
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-08-26
10 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the efforts on this document. Due to lack of time on my side (apologies) I quickly read through the document and …
[Ballot comment]
Thanks for the efforts on this document. Due to lack of time on my side (apologies) I quickly read through the document and didn't find any transport related issue sticking out. I agree with TSVART reviewer (Thanks Tommy Pauly) that this seems useful to reduce duplicate packets to avoid unnecessary effects in the higher layers.

I have two clarification questions:

* Section 5.3.6.2: if there is 6 SIs in the example then why does the it loops through only 5 of them? see the text below -

    On all area edge BFR, bea in
  BIFT:SI=k|k=2...6 is populated with forward_routed(BFRka) and beb in
  BIFT:SI=k with forward_routed(BFRkb).

  For BIER-TE forwarding of a packet to a subset of BFERs across all
  areas, a BFIR would create at most 6 copies, with SI=1...SI=6,

* This might be completely my misunderstanding, however, I understood that BIER-TE supports multiple domains and subdomains, where multiple domains may not be under same implementer. In that case, would their not be issues for BIER-TE controllers to show robust behavior if there is no default ECMP algorithm? Also the implementer is expected to document their ECMP of choice, I didn't understand in what format and to who the documentation applies. Also there is no discussions on what happens if there is no such documentation.
2021-08-26
10 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-08-26
10 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. As I am back from vacations, I am afraid that I had only browsed …
[Ballot comment]
Thank you for the work put into this document. As I am back from vacations, I am afraid that I had only browsed quickly through this dense document, please accept my apologies for that. Please also note that I am not familiar with BIER.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
I find the statement "Co-existence of BIER and BIER-TE forwarding in the same domain is possible, for example by using separate BIER sub-domains (SDs)" quite an oxymoron as co-existence in a single domain requires splitting the domain into sub-domains. Suggest to rather mention sharing the BIFT-id address space among BIER and BIER-TE.
 
In the statement "BIER-TE can also be a good fit to support multicast path steering in Segment Routing (SR) networks" s/can also be a good fit/is shown to be a good fit/ ? Even if section 6 is really light on the topic.

-- Section 1 --
Please expand "BIFT" and "BFR" at first use as other BIER terms are expanded.

-- Section 2.4 --
The blanket/broad statement that "Forwarding of BIER-TE is designed to easily build/program common forwarding hardware with BIER." is it applicable to all hardware handling BIER ? Or is it vendor specific ?

-- Section 3.2.1 --
As BIER-TE is basically centralized in a control, "such YANG/Netconf/RestConf" is a little hand waving. Does the BIER WG have already started work on this control protocol ?

-- Section 4.2.3 --
What is the "entropy parameter" ? where is it defined ? (to repeat myself, I am not a BIER expert) if the entropy is part of the BIER header then strong suggestion to s/entropy parameter/value of the entropy field of the BIER header/.

-- Section 4.3 --
Do the authors have an idea on how to share the BIFT-id address space among BIER (which is decentralized AFAIK) and BIER-TE (which is centralized) without overlapping and keeping the separation during all operations (including when nodes/links appear/disappear) ?

-- Section 6 --
While discussing about SR, did the WG think about using RFC 8986 network programming to achieve the same results as BIER-TE ?

Unsure whether the note about "BIER itself" brings any value in this BIER-TE document.

Unsure what the last § has to do with segment routing.

To be honest, this section is really light and the document would gain by removing it.

== NITS ==

Please use the all uppercase "YANG" rather than "Yang" as it is an acronym.


-- Section 2.3 --
s/that is forwarding plane is a simple extension/that its forwarding plane is a simple extension/ ?
2021-08-26
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-08-26
10 Martin Vigoureux
[Ballot comment]
Hi,

thank you for this work.

Does the text on Segment Routing equally apply to SR-MPLS and SRv6?
Wouldn't an Informative reference to …
[Ballot comment]
Hi,

thank you for this work.

Does the text on Segment Routing equally apply to SR-MPLS and SRv6?
Wouldn't an Informative reference to 8402 be useful?

Couple nits most surely already found:
Expand BIFT and BFR on first use (introduction).
s/designed so that is/designed so that its/.
2021-08-26
10 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-08-26
10 Murray Kucherawy
[Ballot comment]
I had the same question about publication status that Robert did.  We appear to scan automatically for the status of a document in …
[Ballot comment]
I had the same question about publication status that Robert did.  We appear to scan automatically for the status of a document in the same place, and subsequent status changes aren't as attention-getting as they should be.
2021-08-26
10 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-08-25
10 Benjamin Kaduk
[Ballot discuss]
I think there's an issue with the pseudocode in Figure 6.  While I
understand that it's pseudocode, any reasonable interpretation I can
come …
[Ballot discuss]
I think there's an issue with the pseudocode in Figure 6.  While I
understand that it's pseudocode, any reasonable interpretation I can
come up with for the "~" and "&=" operators seems to result in
performing an operation logically equivalent to:

X = AdjacentBits[SI]
Packet->BitString = Packet->BitString & ~X & X

that can be optimized to

Packet->BitString = 0

and I do not think that the only bits that are supposed to be set in the
outgoing packet/packet copy are the ones for which DNC is set -- bits
that we did not find in our BIFT should remain set in outgoing packets.
(Slightly more detail in the COMMENT.)
2021-08-25
10 Benjamin Kaduk
[Ballot comment]
I think it would be helpful to have a clear statement early on that the
DNC bit is applicable only to "forward_connected()" adjacencies …
[Ballot comment]
I think it would be helpful to have a clear statement early on that the
DNC bit is applicable only to "forward_connected()" adjacencies and not
to "forward_routed()", that is, earlier than the guidance in §5.2.1.

It's easy for a reader in a hurry to miss the distinction that just
"BIER" is "regular BIER" as opposed to the "BIER-TE" that this document
specifies.  It might be worth adding a qualifier in at least some
instances about "non-TE BIER" or similar, especially where we have a
paragraph that talks about BIER as a set-up for a comparison with
BIER-TE.

Thanks for the conversation with the gen-art reviewer; I think it's important
to get in the clarifications that were proposed in that thread.

Section 2.3

  BIER-TE is also intended as an option to expand the BIER architecture
  into deployments where BIER may not be the best fit, [...]

It's fairly surprising to advocate for doing something even when there
are known better options to achieve the same goal.

Section 4.3

It seems that these coexistence schemes rely on something like a central
controller entity to configure all BFRs with the criteria for assessing
whether a given packet is in "BIER mode" or "BIER-TE mode".  It seems
prudent to consider the risk that this information is not distributed
uniformly in time (especially in the case of dynamic updates) or
otherwise becomes stale on some particular node(s).  Would the network
be "self-healing" in the face of a node that persistently
mis-forwards/replicates a given class of packet (by virtue of treating
it as BIER rather than BIER-TE, or vice versa)?

Section 4.4

        AdjacentBits = Packet->BitString &= ~AdjacentBits[SI];

The "A = B &= C" construct might be overly clever for what is intended
to be illustrative pseudocode...

        Packet->BitString &= AdjacentBits[SI];

... and the combination of "Packet->BitString &= ~X" and
"Packet->BitString &= X" seems to result in all bits getting cleared, if
I'm not mistaken.  Surely that's not the intent (per the Discuss)...

Section 4.5

I think the example that walks through the packet flow and talks about
which bits are cleared along the way is a helpful example.

Section 5.1.3

  All leaf-BFERs in a BIER-TE domain can share a single bit position.
  This is possible because the bit position for the adjacency to reach
  the BFER can be used to distinguish whether or not packets should
  reach the BFER.

I'm not sure I understand this properly.  I think that this single
shared bit is used both to indicate "send along this adjacency" and
(implicitly?) "local_decap when it gets here".  It seems like this could
result in spurious packet copies egressing from some BFERs.  Consider
(using the left topology from Figure 10) a case where only egress from
BFER2 is needed, but some other constraints meant that the only possible
path from BFIR to BFER2 involved traversing BFR1 on the way to BFR2.
Even though BFR1 only needs to be a transit router for this flow, it
will still send a packet copy to BFER1 (where it gets decapsulated and
sent out).  Even worse, if DNC is not set, it seems that the copy that
leaves BFR1 and makes its way to BFR2 will have the bit cleared that's
used to indicate "leaf BFER".  So, either I'm confused about how this
works (something that's quite plausible!), or there's some other
undocumented constraints here either on the topology or the use of DNC.

Reading forward to the summary in §5.1.10, perhaps my assumption about
indicating "send along this adjacency" was incorrect.  Still, I
shouldn't need to read the later section in order to understand the
earlier one, so adding a few more words here may be in order.

Section 5.1.5

  In a setup with a hub and multiple spokes connected via separate p2p
  links to the hub, all p2p links can share the same bit position.  The

Is this for the adjacency to the hub, from the hub, or the same bit for
both?

Section 5.2.1

  Link layers without port unique link layer addresses should not be
  used with the DNC flag set.

"should not" or "MUST NOT"?

Section 5.2.2

  When links are incorrectly physically re-connected before the BIER-TE
  Controller updates BitStrings in BFIRs, duplicates can happen.  Like
  loops, these can be inhibited by link layer addressing in
  forward_connected() adjacencies.

(Likewise.)

Section 5.3.2

  and the amount of alternative paths in it.  The higher the percentage
  of non-BFER bits, the higher the likelihood, that those topology bits
  are not just BIER-TE overhead without additional benefit, but instead
  that they will allow to express desirable path steering alternatives.

This assessment of likelihood seems unsupportable without some
additional assumptions or preconditions.  If the sampling domain is
"all possible representations of subtopologies" I think the statement is
false.  It only seems likely to hold if the sampling domain is limited
to topology descriptions crafted by BIER-TE experts.

Section 5.3.3

  In BIER-TE, for a non-leaf BFER, there is usually a single BP for
  that BFER with a local_decap() adjacency on the BFER.  The BFR-id for
  such a BFER can therefore equally be determined as in BIER: BFR-id =
  SI * BitStringLength + BP.

I don't think I understand why this constraint is necessary.  What
component is going to know which BFRs are BFERs and rely on this
property of teh BFR-id?

Section 5.3.5

  It is not currently determined if a single sub-domain could or should
  be allowed to forward both BIER and BIER-TE packets.  If this should
  be supported, there are two options:

This sounds kind of Experimental.  Perhaps this content is more
appropriate in an Appendix?

  this approach.  Depending on topology, only the same 20%..80% of bits
  as possible for BIER-TE can be used for BIER.

Where does the 20-80% range come from?

Section 5.3.6.1

  Consider a network setup with a BSL of 256 for a network topology as
  shown in Figure 20.  The network has 6 areas, each with 170 BFRs,
  connecting via a core with 4 (core) BFRs.  To address all BFERs with
  BIER, 4 SIs are required.  To send a BIER packet to all BFER in the

How many BFERs per area?
What calculation produces the "4 SIs are required" result?

Section 5.3.6.2

  On all BFIRs in an area j|j=2...6, bia in each BIFT:SI is populated
  with the same forward_routed(BFRja), and bib with
  forward_routed(BFRjb).  On all area edge BFR, bea in
  BIFT:SI=k|k=2...6 is populated with forward_routed(BFRka) and beb in

Why do j and k range from 2 through 6, excluding 1?  Where is area 1
handled?

Section 6

  Adjacency scope could be global, but then every BFR would need an
  adjacency for this BP, for example a forward_routed() adjacency with
  encapsulation to the global SR SID of the destination.  Such a BP
  would always result in ingress replication though.  The first BFR

I don't think I know what "ingress replication" is.
Are we trying to say that all the replication that occurs for traffic to
this BP is created starting at the ingress node and there can be no
efficiency gains by deferring replication until later on in the path(s)?

  Both BIER and BIER-TE allow BFIR to "opportunistically" copy packets
  to a set of desired BFER on a packet-by-packet basis.  In BIER, this
  is done by OR'ing the BP for the desired BFER.  In BIER-TE this can
  be done by OR'ing for each desired BFER a BitString using the
  "independent branches" approach described in Section 5.3.3 and
  therefore also indicating the engineered path towards each desired
  BFER.  This is the approach that
  [I-D.ietf-bier-multicast-http-response] relies on.

It's a bit late in the day here (so I could be missing something), but
it seems to me that this paragraph is not really needed in this
document.  If it's helpful content, it could appear in the referenced
document, to which it seems more directly applicable.

Section 7

It would be great if (as Roman mentions) we could say that any
BFR/Controller connections used for BIER-TE MUST be protected by TLS or
security protections at least as strong as TLS.

We might consider something like "the discussion in [3272bis] is also
relevant for BIER-TE".

Section 11.2

If "it is expected that the reader be familiar with" RFC 8296, it should
probably be classified as normative.

NITS

By no means an exhaustive collection, but hopefully they will help.

Section 2.2

  may be called an "overlay" BIER-TE topology.  A BIER-TE topology will
  both "forward_connected" and "forward_routed" adjacencies may be
  called a "hybrid" BIER-TE topology.

s/will/with/

Section 2.3

                                                                In BIER-
          TE, bits in the BitString of a BIER packet header indicate an
          adjacency in the BIER-TE topology, and only the BFRs that are
          upstream of this adjacency have this bit populated with the
          adjacency in their BIFT.

I think that s/are upstream/are the upstream endpoint/ would greatly aid
readability.

      2.  In BIER, the implied reference option for the core part of
          the BIER layer control plane is the BIER extension to
          distributed routing protocol, such as standardized in ISIS/
          OSPF extensions for BIER, [RFC8401] and [RFC8444].  [...]

There seems to be some singular/plural mismatch(es) going on here.
Maybe "are the BIER extensions to distributed routing protocols, such as
those standardized in"?

  3.  The following element/functions described in the BIER
      architecture are not required by the BIER-TE architecture:

Probably best to use "elements/functions" to match plurality.

      1.  BIRTs on BFR for BIER-TE are not required when using a BIER-

I think "BFRs" plural.  (Probably the plural is best for the next few
instances of "BFR" (not "BFR-id") in this section, but I will not try to
note them all explicitly.)

Section 3.2

I think s/BFIR/BFIRs/ in all cases in this section (excluding
subsections) other than item 2.3, and possibly 2.1 if the intent is "for
each multicast overlay flow".

      3.  Install state on the BFIR to imposition the desired BIER
          packet header(s) for packets of the overlay flow.

s/imposition/impose/

Section 3.2.1

  o  Data-models and protocols to communicate between controller and
      BFR in step 1, such YANG/Netconf/RestConf.

probably s/BFR/BFRs/ and s/such/such as/.

Section 3.2.1.1

  When the topology is determined, the BIER-TE Controller then pushes
  the BitPositions/adjacencies to the BIFT of the BFRs, populating only
  those SI:BitPositions to the BIFT of each BFR to which that BFR
  should be able to send packets to - adjacencies connecting to this
  BFR.

This sentence should probably be rewritten and split up; it may have
multiple valid parse trees but regardless is pretty hard to parse.
Having separate terms for "the BFR receiving BIFT updates" and "the BFR
to which a given bit says to send a packet" would help a lot.

Section 3.2.1.2

  encoded as the same BitString.  In BIER-TE, the BitString used to
  reach the same set of BFER in the same sub-domain can be different
  for different overlay flows because the BitString encodes the paths
  towards the BFER, so the BitStrings from different BFIR to the same
  set of BFER will often be different, and the BitString from the same
  BFIR to the same set of BFER can different for different overlay
  flows for policy reasons such as shortest path trees, Steiner trees
  (minimum cost trees), diverse path trees for redundancy and so on.

I suggest breaking the sentence before "and the BitString from the same
BFIR".

Also, s/can different/can be different/

  See also [I-D.ietf-bier-multicast-http-response] for a solution
  describing this interaction.

I'm not sure that "solution" is the best word here ("solution to which
problem?").

Section 3.2.1.4

  When link or nodes fail or recover in the topology, BIER-TE could
  quickly respond with out-of-scope FRR procedures such as
  [I-D.eckert-bier-te-frr].  [...]

Is the intent to say "could quickly respond with FRR procedures [...]
the details of which are out of scope for this document"?

Section 3.3

  1.  On BFIR imposition of BIER header for packets from overlay flows.

comma after BFIR

  3.  On BFER removal of BIER header and dispatching of the payload

comma after BFER

Section 3.5

  available at each BFR and for each BP when it is providing congestion
  loss free services such as Rate Controlled Service Disciplines

hyphenate "congestion-loss-free"

  control protocol such as Netconf or any other protocol commonly used
  by a PCE to understand the resources of the network it operates on.

I think s/PCE/Controller/ since this is the only instance of "PCE"
that's not part of "PCEP", in this document.

  the BIER-TE defined steering of packets.  This includes allocation of
  buffers to guarantee the worst case requirements of admitted RCSD
  traffic and potential policing and/or rate-shaping mechanisms,

I'm not sure, but possibly s/potential/potentially/

Section 4.2.1

  for copies of the packet made towards other adjacencies.  This can be
  used for example in ring topologies as explained below.

"Below" could become a reference to §5.1.6 as was done in §4.1.

Section 4.2.3

  packet is copied onto such an ECMP adjacency, an implementation
  specific so-called hash function will select one out of the lists
  adjacencies to which the packet is forwarded.  This ECMP hash

s/lists/list's/

Section 4.2.4

  packets.  Local_decap() adjacencies require the BFER to support
  routing or switching for NextProto to determine how to further
  process the packet.

I'm not finding a protocol element to map to "NextProto" in this
context, so maybe writing out in long form something like "the next
protocol layer" would be preferred.

Section 4.3

  With MPLS, it is also possible to reuse the same SD space for both
  BIER-TE and BIER, so that the same SD has both a BIER BIFT and
  according range of BIFT-ids and a disjoint BIER-TE BIFT and non-
  overlapping range of BIFT-ids.

I think s/according/corresponding/

  "forward_routed" requires an encapsulation permitting to unicast
  BIER-TE packets to a specific interface address on a target BFR.

"encapsulation that permits directing unicast BIER-TE packets"

Section 4.4

      void ForwardBitMaskPacket_withTE (Packet)
      {
          SI=GetPacketSI(Packet);
          Offset=SI*BitStringLength;
          for (Index = GetFirstbit position(Packet->BitString); Index ;
              Index = GetNextbit position(Packet->BitString, Index)) {
              F-BM = BIFT[Index+Offset]->F-BM;
              if (!F-BM) continue;                            [3]
              BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
              PacketCopy = Copy(Packet);
              PacketCopy->BitString &= F-BM;                  [2]
              PacketSend(PacketCopy, BFR-NBR);
              // The following must not be done for BIER-TE:
              // Packet->BitString &= ~F-BM;                  [1]
          }
      }

GetFirstBitPosition and GetNextBitPosition are the spellings used in the
RFC 8279 pseudocode; I don't see reason to diverge from them.  (The same
comment applies to the pseudocode in Figure 6 as well.)

  To solve both [1] and [2] for BIER, the F-BM of each bit needs to
  have all bits set that this BFR wants to route across BFR-NBR. [2]

Expanded out, "the F-BM of each bit needs to have" doesn't seem to make
much sense; would s/bit/bit index/ make more sense?

      *  The packets BitString is masked with those AdjacentBits before
        the loop to avoid doing this repeatedly for every PacketCopy.

s/packets/packet's/

                    case forward_routed({VRF},neighbor):
                        SendToL3(PacketCopy,{VRF,}l3-neighbor);

Should the first line use "l3-neighbor" as well as the second one?

Section 4.5

  BFR3 sees a BitString of p5,p7,p8,p10,p11,p12.  For those BPs, it has
  only adjacencies for p7,p8.  It creates a copy of the packet to BFER1
  (due to p7) and one to BFR4 (due to p8).  It clears p7, p8 before
  sending.

I think "clears both p7 and p8 in both copies before sending" is more
clear.

Section 4.6

  clear DNC flag, forward_routed() and local_decap.  As explained in
  Section 4.4, these REQUIRED BIER-TE forwarding functions can be
  implement via the same Forwarding Pseudocode as BIER forwarding

s/implement/implemented/

Section 5.1.4

  opposite LANs.  Adjacencies of such BFRs into their LAN still need a
  separate bit position.

Is this something like "such multi-homed BFRs"?

Section 5.1.9

                          Figure 17: Reuse of BP

  Reuse may also save BPs in larger topologies.  Consider the topology
  shown in Figure 20.  A BFIR/sender (e.g.: video headend) is attached

I suspect that s/20/17/ is intended.

Section 5.1.10

  o  BP can generally be reused across nodes that do not need to be
      consecutive in paths, but depending on scenario, this may limit

"consecutive in paths" might imply "directly one after the other" to
some readers.  Perhaps "where it can be guaranteed that no path will
ever need to traverse more than one node of the set"?

Section 5.3.3

  BIER-TE forwarding does not use the BFR-id, not does it require for

s/not does/nor does/

Section 5.3.6.2

  In addition, we use 4 bits in each SI: bia, bib, bea, beb: bit
  ingress a, bit ingress b, bit egress a, bit egress b.  These bits

It's probably worth spending a few more words to connect these "a" and
"b" back to the 6 different BFR1a/BFR1b through BFR6a/BFR6b of Figure
20.  (Figure 20, which appears in §5.3.6.1, is not mentioned at all from
this section at present.)

  legs: 1) BFIR to ingress are edge and 2) core to egress area edge.

s/are edge/area edge/

Section 6

  hop to each destination Node-SID.  What BIER does not allow is to
  indicate intermediate hops, or terms of SR the ability to indicate a

s/terms of SR/in terms of SR/

Section 7

  In BIER, the standardized methods for the routing underlays as well
  as to distribute BFR-ids and BFR-prefixes are IGPs such as specified
  in [RFC8401] for IS-IS and in [RFC8444] for OSPF.  Attacking the

I can't make a parse tree for this sentence.  I think it's just trying
to say that RFCs 8401 and 8444 specify how to distribute BFR-ids and
BFR-prefixes over the respective IGP, and the respective IGP inherently
distributes information needed for routing underlays, but I could be
wrong.

  against the results of the routing protocol, enabling DoS attacks
  against paths or addressing (BFR-id, BFR-prefixes) used by BIER.

I think s/addressing/the addressing/

  adjacencies, then this is still an attack vector as in BIER, but only
  for BIER-TE forward_routed() adjacencies, and no other adjacencies.

s/and no/and not/

  the BIER-TE controller/control-plane can and are much more commonly

s/can/can be/

  forwarding rules are defined to be as strict in clearing bits as they
  are.  The clearing of all bits with an adjacency on a BFR prohibits

I think just "defined to be as strict in clearing bits as possible" --
"defined to be as  as they are" is basically a tautology.

  that a looping packet creates additional packet amplification through
  the misconfigured loop on the packets second or further times around

s/packets/packet's/

  Deployments especially where BIER-TE would likely be beneficial may
  include operational models where actual configuration changes from

This "especially" seems out of place (I think the sentence would work if
it's just dropped, though maybe moving it is preferred).

  the controller are only required during non-productive phases of the

Maybe s/productive/production/?

  networks life-cycle, such as in embedded networks or in manufacturing

s/networks/network's/ (just the first one)

  reverting the network/installation into non-productive state.  Such

("production" again)
2021-08-25
10 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-08-25
10 Roman Danyliw
[Ballot comment]
** Section 2.3.  What is “ships in the nights forwarding”?  Is this intended to convey that packets are forwarded mutually exclusively either via …
[Ballot comment]
** Section 2.3.  What is “ships in the nights forwarding”?  Is this intended to convey that packets are forwarded mutually exclusively either via BIER or BIER-TE?

** Section 4.4.  I appreciate that this is pseudocode so there isn’t a strict syntax to reference.  The following syntax of {VRF,}” wasn’t clear to me:

SendToL3(PacketCopy,{VRF,}l3-neighbor

PassTo(PacketCopy,{VRF,}Packet->NextProto);

Is that a typo for “{VRF}?

** Section 5.1.5.  Per “This type of optimization BP could be used for example when all traffic is broadcast traffic … such as … situational awareness (SA)”, is SA some notification service (e.g., an emergency alert)?

** Section 7.  Per the Security Considerations of RFC8279, it says:

If the BIER encapsulation of a packet is
  modified (through error or malfeasance) in a way other than that
  specified in this document, the packet may be misdelivered.

In additional, relevant here and in RFC8279 would be that modification of the BIER encapsulation not only could lead to mis-delivery (noted in RFC8279) but also routing through an alternative path of the attackers choosing enabling additional inspection.

** Section 7. 
  ... communications
  between controllers and routers such as those to be considered for
  the BIER-TE controller/control-plane can and are much more commonly
  secured with those security properties, for example by using Secure
  SHell (SSH), [RFC4253] for NetConf ([RFC6241]), or via Transport
  Layer Security (TLS), such as [RFC8253] for PCEP, [RFC5440], or
  [RFC7589] for NetConf.

I wasn’t able to discern from the shepherd’s write-up if BIER-TE has implementations or is seeing deployment.  Especially, if this is a green field space, can a stronger statement be made about requiring or at least recommending a secure transport between the controller and routers?  The text seems to present ample enabling technologies to realize this more secure communication (i.e. “… for example by using Secure SHell (SSH), [RFC4253] for NetConf ([RFC6241]), or via Transport Layer Security (TLS), such as [RFC8253] for PCEP, [RFC5440], or  [RFC7589] for NetConf.”)

** Section 7. 

  In
  addition, the security considerations of [RFC4655] apply.

Section 10 (Security Considerations) of RFC4655 uses architectural concepts of like “inter and intra-domain networks”, “multi-domain network” and “non-local PCE”.  I wanted to clarify how to overlaying these concepts to the text in this document.  For example,

-- is operating multiple “BIER sub-domains” correspond to a “multi-domain” network”?

-- what would a “non-local PCE” be in this BIER-TE architecture?


** Editorial

-- Section 2.1.  Figure 1. Editorial. s/local_decap/local_decap()/

-- Section 2.1.  Editorial.  s/The following picture shows/Figure 2 shows/

-- Section 2.3.  Editorial.  Typo. s/See for example See Section 5.1.3/See Section 5.1.3/

-- Section 4.3. 
  When a fixed mapping from BSL, SD, SI is used without specifically
  distinguishing BIER and BIER-TE, such as proposed for non-MPLS
  forwarding with [RFC8296] in [I-D.ietf-bier-non-mpls-bift-encoding]
  revision 04, section 5., then it is necessary to allocate disjoint
  SDs to BIER and BIER-TE BIFT so that both can be addressed by the
  BIFT-ids. 

(a) (Editorial) This sentence doesn’t parse.

(b) I would recommend against citing a specific version of an ID (Section 5 of -04)

-- Section 4.6.  The phrases “BFR MUST support to configure the BIFT …” and “Every BP in the BIFT MUST support to have zero …” do not parse.
2021-08-25
10 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-08-25
10 Robert Wilton
[Ballot comment]
Thanks for your work on this document.

Discuss cleared based on Alvaro's clarification - I was misdirected by the boilerplate of the documents …
[Ballot comment]
Thanks for your work on this document.

Discuss cleared based on Alvaro's clarification - I was misdirected by the boilerplate of the documents having the wrong status on both tools and datatracker, but the status is right on the RFC editor website and in the datatracker metadata.

I've moved the question regarding whether RFC 8296 should be a normative reference to a non-blocking comment.

I'm not an expert on the BIER technology, and I didn't have the time to properly read the core references before reviewing this document.  However, I didn't spot any obvious issues on the text, beyond the question on the document status.  But I also appreciated the detailed section on the operational considerations related to managing the bit position assignments, which I interpret not as a strict requirement of this specification, but likely to be very helpful to controller implementations and operators.

Regards,
Rob
2021-08-25
10 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2021-08-25
10 Robert Wilton
[Ballot discuss]
Hi,

I would like to please double check with the authors, responsible AD, and IESG that publishing this as standards track is the …
[Ballot discuss]
Hi,

I would like to please double check with the authors, responsible AD, and IESG that publishing this as standards track is the right choice (as opposed to experimental).

From the first line of the introduction:
"BIER-TE is based on architecture, terminology and packet formats with
  BIER as described in [RFC8279] and [RFC8296].

Both RFC 8279 and RFC 8296 are experimental RFCs, hence (1) I wanted to check that by publishing this draft as Std Track, that this draft isn't being built on an unstable footing.

This draft has a normative reference to RFC 8279, but only an informative reference to RFC 8296.

Hence, I further wanted to check:
(2) Should RFC 8296 really be a normative reference?
(3) The IETF LC announcement didn't seem to flag the downref to RFC 8279RFC 8067 says that is not strictly required, but in this case I think that would have been useful.

I can see from the document history that the WG has flip-flopped on whether this document should be experimental or stds track, but I couldn't quickly find this discussion, and it wasn't covered in shepherds writeup.  If it is possible for someone to provide a quick summary as to why it is okay and right to publish this as standards track that would be appreciated.
2021-08-25
10 Robert Wilton
[Ballot comment]
Thanks for your work on this document.

I'm not an expert on the BIER technology, and I didn't have the time to properly …
[Ballot comment]
Thanks for your work on this document.

I'm not an expert on the BIER technology, and I didn't have the time to properly read the core references before reviewing this document.  However, I didn't spot any obvious issues on the text, beyond the question on the document status.  But I also appreciated the detailed section on the operational considerations related to managing the bit position assignments, which I interpret not as a strict requirement of this specification, but likely to be very helpful to controller implementations and operators.

Regards,
Rob
2021-08-25
10 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2021-08-24
10 Erik Kline
[Ballot comment]
[S2.1, comment]

* "A packet from BFR1 to BFR3,BFR4 and from BFR4 to BFR uses (p1,p2,p3,p4,p6)"

  ->

  "A packet from BFR1 …
[Ballot comment]
[S2.1, comment]

* "A packet from BFR1 to BFR3,BFR4 and from BFR4 to BFR uses (p1,p2,p3,p4,p6)"

  ->

  "A packet from BFR1 to BFR3,BFR4 and from BFR4 to BFR6 uses (p1,p2,p3,p4,p6)"

  ...I think.

[S4.2.2,4.3 comment]

* Both of these forward_routed() encap sections have no apparent mention
  of MTU considerations.  Maybe just drop a handy reference in one of these
  sections to the text in RFC 8296 section 3?
2021-08-24
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-08-24
10 Ines Robles Request for Telechat review by RTGDIR Completed: Has Nits. Reviewer: Ines Robles. Sent review to list.
2021-08-24
10 Lars Eggert
[Ballot comment]
Robert Spark's GenART review on Aug 8 flagged a long list of issues and
nits that I haven't seen a response to yet. …
[Ballot comment]
Robert Spark's GenART review on Aug 8 flagged a long list of issues and
nits that I haven't seen a response to yet. Please respond to Robert.

Section 1. , paragraph 12, comment:
>    Bloom filters in general can support larger trees/topologies with
>    fewer addressing bits than explicit BitStrings, but they introduce
>    the heuristic risk of false positives and cannot clear bits in the
>    BitString during forwarding to avoid loops.  For these reasons, BIER-
>    TE uses explicit BitStrings like BIER.  The explicit BitStrings of
>    BIER-TE can also be seen as a special type of Bloom filter, and this
>    is how related work [ICC] describes it.

There is research work on Bloom filters without false positives, e.g.,
https://ieeexplore.ieee.org/document/8486415. Don't want to start a long
debate, but was just wondering if these newer approaches wouldn't be suitable?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:
 
* Term "native"; alternatives might be "built-in", "fundamental",
  "ingrained", "intrinsic", "original".
 
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.3. , paragraph 2, nit:
-    BIER-TE is designed so that is forwarding plane is a simple extension
+    BIER-TE is designed so that its forwarding plane is a simple extension
+                                +

Section 5.3.3. , paragraph 7, nit:
-    that is unique to the BFR in question.  For a BFIR this can be he
+    that is unique to the BFR in question.  For a BFIR this can be the
+                                                                  +

Section 2.1. , paragraph 15, nit:
> ies are called "forward_routed". Otherwise there is no difference in their p
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Otherwise".

Section 2.2. , paragraph 3, nit:
> The BIER forwarding plane, with the exception of how bits have to be cleared
>                            ^^^^^^^^^^^^^^^^^^^^^
Consider using "except" or "except for".

Section 3.2.1.1. , paragraph 4, nit:
> ne The BIER-TE Forwarding Plane constitutes of the following components: 1. O
>                                ^^^^^^^^^^^^^^
Did you mean "consists of"?

Section 4.1. , paragraph 5, nit:
> meter. The seed parameter allows to design hash functions that are easy to i
>                                  ^^^^^^^^^
Did you mean "designing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 4.4. , paragraph 6, nit:
> A DID NOT MIND ANOTHER EXAMPLE. Step by step example of basic BIER-TE forwar
>                                ^^^^^^^^^^^^
Did you mean the adjective or adverb "Step-by-step" (spelled with hyphens)?

Section 4.4. , paragraph 23, nit:
> ER-TE forwarding functions can be implement via the same Forwarding Pseudocod
>                                  ^^^^^^^^^
The past participle is required after "can be".

Section 4.5. , paragraph 5, nit:
> re Non-Leaf BFER as shown on the right hand side, one traffic copy would be
>                                  ^^^^^^^^^^
Did you mean the adjective "right-hand"?

Section 4.5. , paragraph 5, nit:
> hich makes BFER2 a non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forw
>                                  ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Likewise".

Section 4.5. , paragraph 5, nit:
> FER2. Note that the BFERs in the left hand picture are only guaranteed to be
>                                  ^^^^^^^^^
Did you mean the adjective "left-hand"?

Section 4.5. , paragraph 9, nit:
> BFER can be used to distinguish whether or not packets should reach the BFER.
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 5.1.2. , paragraph 1, nit:
> h (ECMP) The ECMP adjacency allows to use just one BP per link bundle between
>                                    ^^^^^^
Did you mean "using"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 5.1.6. , paragraph 9, nit:
> ted() adjacencies can also allow to operate BIER-TE across intermediate hop
>                                  ^^^^^^^^^^
Did you mean "operating"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 5.1.7. , paragraph 1, nit:
> that have arrived at BFR1 or BFR4 via a shortest path in the routing underlay
>                                      ^
Use "the" before the superlative.

Section 5.1.10. , paragraph 9, nit:
>  but instead that they will allow to express desirable path steering alternat
>                                  ^^^^^^^^^^
Did you mean "expressing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 5.2.1. , paragraph 10, nit:
> rlay applications to operate independently from the controller whenever it n
>                              ^^^^^^^^^^^^^^^^^^
The usual collocation for "independently" is "of", not "from". Did you mean
"independently of"?

Document references draft-ietf-bier-multicast-http-response-05, but -06 is the
latest available revision.

Document references draft-ietf-bier-non-mpls-bift-encoding-03, but -04 is the
latest available revision.

Document references draft-ietf-bier-te-yang-02, but -03 is the latest available
revision.

Document references draft-ietf-teas-rfc3272bis-11, but -12 is the latest
available revision.

These URLs in the document can probably be converted to HTTPS:
* http://www.github.com/toerless/bier-te-arch
2021-08-24
10 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-08-20
10 Yingzhen Qu Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Yingzhen Qu. Sent review to list.
2021-08-19
10 Bernie Volz Request for Telechat review by INTDIR is assigned to Suzanne Woolf
2021-08-19
10 Bernie Volz Request for Telechat review by INTDIR is assigned to Suzanne Woolf
2021-08-19
10 Bernie Volz Request for Telechat review by INTDIR is assigned to Juan-Carlos Zúñiga
2021-08-19
10 Bernie Volz Request for Telechat review by INTDIR is assigned to Juan-Carlos Zúñiga
2021-08-19
10 Éric Vyncke Requested Telechat review by INTDIR
2021-08-18
10 Éric Vyncke Requested Telechat review by INTDIR
2021-08-17
10 Martin Duke
[Ballot comment]
Thanks to Tommy Pauly for the TSVART review.

(2.1) s/p1...p14/p1...p15

(4.4) I had to read this section several times to understand the F-BM …
[Ballot comment]
Thanks to Tommy Pauly for the TSVART review.

(2.1) s/p1...p14/p1...p15

(4.4) I had to read this section several times to understand the F-BM logic. Here are some suggestions to clarify it:

s/F-BM is handled as follows/F-BM is generated as follows: "handled" is similar "processed", which is not what I think you mean.

"All bits with an adjacency.. has only those bits set for which this BFR does not have an adjacency." This sentence was very confusing for me until I grasped that there were two different bitmaps here: the first reference to 'bits' is the BitString, the second reference is the F-BM, which has no direct relation to the BitString. More introductory text to specify the two bitmaps, and be clear about which bitmap each reference to 'bit' refers to, would be helpful.

(5.1) What does "(4.1, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8)" mean?

(5.1.3) Another situation where Leaf BFER's can't fully collapse into one codepoint is if there are two local_decap() interfaces. Or does this concept not logically exist?
2021-08-17
10 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-08-13
10 Luc André Burdet Request for Telechat review by RTGDIR is assigned to Ines Robles
2021-08-13
10 Luc André Burdet Request for Telechat review by RTGDIR is assigned to Ines Robles
2021-08-13
10 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Yingzhen Qu
2021-08-13
10 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Yingzhen Qu
2021-08-11
10 Amy Vezza Placed on agenda for telechat - 2021-08-26
2021-08-11
10 Alvaro Retana Ballot has been issued
2021-08-11
10 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2021-08-11
10 Alvaro Retana Created "Approve" ballot
2021-08-11
10 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2021-08-11
10 Alvaro Retana Ballot writeup was changed
2021-08-11
10 Alvaro Retana Requested Telechat review by RTGDIR
2021-08-11
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-08-09
10 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2021-08-09
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-bier-te-arch-10, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-bier-te-arch-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-08-07
10 Robert Sparks Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks. Sent review to list.
2021-08-04
10 Tommy Pauly Request for Last Call review by TSVART Completed: Ready. Reviewer: Tommy Pauly. Sent review to list.
2021-07-28
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2021-07-28
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2021-07-23
10 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2021-07-23
10 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2021-07-22
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stefan Santesson
2021-07-22
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stefan Santesson
2021-07-21
10 Magnus Westerlund Request for Last Call review by TSVART is assigned to Tommy Pauly
2021-07-21
10 Magnus Westerlund Request for Last Call review by TSVART is assigned to Tommy Pauly
2021-07-20
10 Alvaro Retana Requested Last Call review by RTGDIR
2021-07-20
10 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-07-20
10 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-08-11):

From: The IESG
To: IETF-Announce
CC: Xuesong Geng , aretana.ietf@gmail.com, bier-chairs@ietf.org, bier@ietf.org, …
The following Last Call announcement was sent out (ends 2021-08-11):

From: The IESG
To: IETF-Announce
CC: Xuesong Geng , aretana.ietf@gmail.com, bier-chairs@ietf.org, bier@ietf.org, draft-ietf-bier-te-arch@ietf.org, gengxuesong@huawei.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Tree Engineering for Bit Index Explicit Replication (BIER-TE)) to Proposed Standard


The IESG has received a request from the Bit Indexed Explicit Replication WG
(bier) to consider the following document: - 'Tree Engineering for Bit Index
Explicit Replication (BIER-TE)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-08-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This memo describes per-packet stateless strict and loose path
  steered replication and forwarding for Bit Index Explicit Replication
  packets (RFC8279).  It is called BIER Tree Engineering (BIER-TE) and
  is intended to be used as the path steering mechanism for Traffic
  Engineering with BIER.

  BIER-TE introduces a new semantic for bit positions (BP) that
  indicate adjacencies, as opposed to BIER in which BPs indicate Bit-
  Forwarding Egress Routers (BFER).  BIER-TE can leverage BIER
  forwarding engines with little changes.  Co-existence of BIER and
  BIER-TE forwarding in the same domain is possible, for example by
  using separate BIER sub-domains (SDs).  Except for the optional
  routed adjacencies, BIER-TE does not require a BIER routing underlay,
  and can therefore operate without depending on an Interior Gateway
  Routing protocol (IGP).

  As it operates on the same per-packet stateless forwarding
  principles, BIER-TE can also be a good fit to support multicast path
  steering in Segment Routing (SR) networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2766/





2021-07-20
10 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-07-20
10 Alvaro Retana Last call was requested
2021-07-20
10 Alvaro Retana Ballot approval text was generated
2021-07-20
10 Alvaro Retana Ballot writeup was generated
2021-07-20
10 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-07-20
10 Alvaro Retana Last call announcement was changed
2021-07-20
10 Alvaro Retana Last call announcement was generated
2021-07-09
10 (System) Changed action holders to Alvaro Retana (IESG state changed)
2021-07-09
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-07-09
10 Toerless Eckert New version available: draft-ietf-bier-te-arch-10.txt
2021-07-09
10 (System) New version accepted (logged-in submitter: Toerless Eckert)
2021-07-09
10 Toerless Eckert Uploaded new revision
2021-05-26
09 Xuesong Geng
Changes are expected over time. This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, …
Changes are expected over time. This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?


draft-ietf-bier-te-arch is proposed Standard track.

Why is this the proper type of RFC?

This is indicated on the title page. This document defines BIER tree engineering mechanism by changing the semantics of bit position that has been defined in RFC 8279, which provides traffic steering within BIER forwarding architecture.

Is this type of RFC indicated in the title page header?

Yes

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This draft presents a stateless path steering mechanism for BIER, called BIER TE (Tree Engineering for Bit Index Explicit Replication). Bitstring sematic of BIER-TE is different from BIER defined in RFC 8279, which indicates adjacencies, but it could reuse the forwarding engine of BIER. The BIFT of each BFR only contains the BPs that are adjacent to the BFR in BIER-TE topology. BIER-TE doesn’t depend on any IGP protocols as routing underlay.

Working Group Summary:

The name of the mechanism defined in the draft has been discussed during last call, which was changed from “BIER traffic engineering” to “BIER tree engineering”, considering that it only covers the path steering function in the overall solution of traffic engineering. Any BIER traffic engineering mechanism could use this mechanism.
As the result of the WG discussion, “Name explanation” part is added to the document, which will be removed in the next version.

Document Quality:

After full discussions and multiple revisions, there is solid consensus for this document in WG. It is ready for publication . No implementation was yet announced in the BIER WG. No formal language is used in the document (there is some informal pseudo-code without formal verification tools). No aspects of the document required expert review.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Geng Xuesong is the shepherd and Alvaro Retana is the Responsible Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd has reviewed the version 8 of draft-ietf-bier-te-arch. Her concerns where addressed by the authors in version 9. She believes this version is now ready for forwarding to the IESG for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Yes. See acknowledgement section for list of key reviewers, including Lou Berger, TEAS chair. This document has been reviewed, and there is no concern about depth or breadth about the previous reviews.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The shepherd has no concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The Shepherd received confirmation from all authors that all IPR they are aware of has been disclosed to the IETF:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bier-te-arch

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is no IPR-related discussion.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG consensus for this draft is very solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Negative.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The shepherd has verified idnits. Only warnings where found by the tools which have been identified to be issues of the idnits tools, not of the document. The intend status of the document is correctly indicated, formal review criteria are met (are not applicable).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not relevant.

(13) Have all references within this document been identified as either normative or informative?

Yes the document is split to normative and informative references. Documents that are normative references are in a clear state (no pending or downrevs).

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document requests no action by IANA.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not relevant.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not relevant.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not relevant.

2021-05-14
09 Alvaro Retana === AD Review of draft-ietf-bier-te-arch-09 ===
https://mailarchive.ietf.org/arch/msg/bier/nnVGGEVt6GbNh3h1D3UJ-cIRvys/
2021-05-14
09 (System) Changed action holders to Toerless Eckert, Michael Menth, Gregory Cauchie, Alvaro Retana (IESG state changed)
2021-05-14
09 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-03-30
09 (System) Changed action holders to Alvaro Retana (IESG state changed)
2021-03-30
09 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2021-03-30
09 Alvaro Retana Notification list changed to Xuesong Geng <gengxuesong@huawei.com>, aretana.ietf@gmail.com from Xuesong Geng <gengxuesong@huawei.com>
2020-12-10
09 Greg Shepherd


(As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. This version is dated …


(As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012)


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-bier-te-arch is Proposed Standard. This is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary 

This draft presents a stateless path steering mechanism for BIER, called BIER TE (Tree Engineering for Bit Index Explicit Replication). Bitstring sematic of BIER-TE is different from BIER defined in RFC 8279, which indicates adjacencies, but it could reuse the forwarding engine of BIER. The BIFT of each BFR only contains the BPs that are adjacent to the BFR in BIER-TE topology. BIER-TE doesn’t depend on any IGP protocols as routing underlay.

Working Group Summary

The name of the mechanism defined in the draft has been discussed during last call, which was changed from “BIER traffic engineering” to “BIER tree engineering”, considering that it only covers the path steering function in the overall solution of traffic engineering. Any BIER traffic engineering mechanism could use this mechanism.

Document Quality

After full discussions and multiple revisions, there is solid consensus for this document in WG. It is ready for adoption. No implementation was yet announced in the BIER WG. No formal language is used in the document (there is some informal pseudo-code without formal verification tools). No aspects of the document required expert review.

Personnel

Who is the Document Shepherd? Who is the Responsible Area  Director?

Geng Xuesong is the shepherd and Alvaro Retana is the Responsible Area Director

1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Geng Xuesong, Yes she has reviewed the version 8 of draft-ietf-bier-te-arch. Her concerns where addressed by the authors in version 9. She believes this version is now ready for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes. See acknowledgement section for list of key reviewers, including Lou Berger, TEAS chair. This document has been reviewed, and there is no concern about depth or breadth about the previous reviews..

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The shepherd has no concerns.

The Shepherd received confirmation from all authors that all IPR they are aware of has been disclosed to the IETF:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bier-te-arch


  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The WG consensus for this draft is very solid.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

Negative.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Yes, the shepherd has verified idnits. Only warnings where found by the tools which have been identified to be issues of the idnits tools, not of the document. The intend status of the document is correctly indicated, formal review criteria are met (are not applicable).

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes the document is split to normative and informative references. Documents that are normative references are in a clear state (no pending or downrevs).

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

This document requests no action by IANA.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No applicable.
2020-12-10
09 Greg Shepherd Responsible AD changed to Alvaro Retana
2020-12-10
09 Greg Shepherd IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-12-10
09 Greg Shepherd IESG state changed to Publication Requested from I-D Exists
2020-12-10
09 Greg Shepherd IESG process started in state Publication Requested
2020-12-08
09 Greg Shepherd IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-11-03
09 Xuesong Geng


(As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. This version is dated …


(As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012)


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-bier-te-arch is Proposed Standard. This is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary 

This draft presents a stateless path steering mechanism for BIER, called BIER TE (Tree Engineering for Bit Index Explicit Replication). Bitstring sematic of BIER-TE is different from BIER defined in RFC 8279, which indicates adjacencies, but it could reuse the forwarding engine of BIER. The BIFT of each BFR only contains the BPs that are adjacent to the BFR in BIER-TE topology. BIER-TE doesn’t depend on any IGP protocols as routing underlay.

Working Group Summary

The name of the mechanism defined in the draft has been discussed during last call, which was changed from “BIER traffic engineering” to “BIER tree engineering”, considering that it only covers the path steering function in the overall solution of traffic engineering. Any BIER traffic engineering mechanism could use this mechanism.

Document Quality

After full discussions and multiple revisions, there is solid consensus for this document in WG. It is ready for adoption. No implementation was yet announced in the BIER WG. No formal language is used in the document (there is some informal pseudo-code without formal verification tools). No aspects of the document required expert review.

Personnel

Who is the Document Shepherd? Who is the Responsible Area  Director?

Geng Xuesong is the shepherd and Alvaro Retana is the Responsible Area Director

1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Geng Xuesong, Yes she has reviewed the version 8 of draft-ietf-bier-te-arch. Her concerns where addressed by the authors in version 9. She believes this version is now ready for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes. See acknowledgement section for list of key reviewers, including Lou Berger, TEAS chair. This document has been reviewed, and there is no concern about depth or breadth about the previous reviews..

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The shepherd has no concerns.

The Shepherd received confirmation from all authors that all IPR they are aware of has been disclosed to the IETF:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bier-te-arch


  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The WG consensus for this draft is very solid.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

Negative.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Yes, the shepherd has verified idnits. Only warnings where found by the tools which have been identified to be issues of the idnits tools, not of the document. The intend status of the document is correctly indicated, formal review criteria are met (are not applicable).

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes the document is split to normative and informative references. Documents that are normative references are in a clear state (no pending or downrevs).

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

This document requests no action by IANA.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No applicable.
2020-10-30
09 Toerless Eckert New version available: draft-ietf-bier-te-arch-09.txt
2020-10-30
09 (System) New version accepted (logged-in submitter: Toerless Eckert)
2020-10-30
09 Toerless Eckert Uploaded new revision
2020-07-13
08 Toerless Eckert New version available: draft-ietf-bier-te-arch-08.txt
2020-07-13
08 (System) New version approved
2020-07-13
08 (System) Request for posting confirmation emailed to previous authors: Toerless Eckert , bier-chairs@ietf.org, Michael Menth , Gregory Cauchie
2020-07-13
08 Toerless Eckert Uploaded new revision
2020-07-13
07 Greg Shepherd Notification list changed to Xuesong Geng <gengxuesong@huawei.com>
2020-07-13
07 Greg Shepherd Document shepherd changed to Xuesong Geng
2020-03-09
07 Toerless Eckert New version available: draft-ietf-bier-te-arch-07.txt
2020-03-09
07 (System) New version approved
2020-03-09
07 (System) Request for posting confirmation emailed to previous authors: Gregory Cauchie , Michael Menth , bier-chairs@ietf.org, Toerless Eckert
2020-03-09
07 Toerless Eckert Uploaded new revision
2020-02-19
06 Toerless Eckert New version available: draft-ietf-bier-te-arch-06.txt
2020-02-19
06 (System) New version approved
2020-02-19
06 (System) Request for posting confirmation emailed to previous authors: Toerless Eckert , Gregory Cauchie , Michael Menth , bier-chairs@ietf.org
2020-02-19
06 Toerless Eckert Uploaded new revision
2019-11-01
05 Toerless Eckert New version available: draft-ietf-bier-te-arch-05.txt
2019-11-01
05 (System) New version accepted (logged-in submitter: Toerless Eckert)
2019-11-01
05 Toerless Eckert Uploaded new revision
2019-10-23
04 Toerless Eckert New version available: draft-ietf-bier-te-arch-04.txt
2019-10-23
04 (System) New version approved
2019-10-23
04 (System) Request for posting confirmation emailed to previous authors: Toerless Eckert , Gregory Cauchie , Michael Menth , bier-chairs@ietf.org
2019-10-23
04 Toerless Eckert Uploaded new revision
2019-09-20
03 Tony Przygienda IETF WG state changed to In WG Last Call from WG Document
2019-07-08
03 Toerless Eckert New version available: draft-ietf-bier-te-arch-03.txt
2019-07-08
03 (System) New version approved
2019-07-08
03 (System) Request for posting confirmation emailed to previous authors: Toerless Eckert , Gregory Cauchie , Michael Menth , Wolfgang Braun , bier-chairs@ietf.org
2019-07-08
03 Toerless Eckert Uploaded new revision
2019-05-30
02 Greg Shepherd Changed consensus to Yes from Unknown
2019-05-30
02 Greg Shepherd Intended Status changed to Proposed Standard from None
2019-05-14
02 Toerless Eckert New version available: draft-ietf-bier-te-arch-02.txt
2019-05-14
02 (System) New version approved
2019-05-14
02 (System) Request for posting confirmation emailed to previous authors: Toerless Eckert , Gregory Cauchie , Michael Menth , Wolfgang Braun , bier-chairs@ietf.org
2019-05-14
02 Toerless Eckert Uploaded new revision
2019-04-26
01 (System) Document has expired
2018-10-23
01 Toerless Eckert New version available: draft-ietf-bier-te-arch-01.txt
2018-10-23
01 (System) New version approved
2018-10-23
01 (System) Request for posting confirmation emailed to previous authors: Toerless Eckert , Gregory Cauchie , Michael Menth , Wolfgang Braun , bier-chairs@ietf.org
2018-10-23
01 Toerless Eckert Uploaded new revision
2018-07-27
00 (System) Document has expired
2018-03-22
00 Lou Berger Added to session: IETF-101: detnet  Fri-0930
2018-01-23
00 Greg Shepherd This document now replaces draft-eckert-bier-te-arch instead of None
2018-01-23
00 Toerless Eckert New version available: draft-ietf-bier-te-arch-00.txt
2018-01-23
00 (System) WG -00 approved
2018-01-23
00 Toerless Eckert Set submitter to "Toerless Eckert ", replaces to draft-eckert-bier-te-arch and sent approval email to group chairs: bier-chairs@ietf.org
2018-01-23
00 Toerless Eckert Uploaded new revision