Bit Indexed Explicit Replication
charter-ietf-bier-02

[Ballot comment]
I support Alissa's BLOCK.

Some of the proposed deliverables appear to potentially be support documents  -- items 3) and 8) in particular appear to fall into this category. I would like to see the charter explicitly indicate, for each of these two deliverables, whether the documents will be proposed for publication as RFCs.

[Ballot comment]
There's no mention of security.  I know the options aren't great with MPLS, but is there anything that could/should be done?  It's late or I'd have better suggestions. I wanted to note this gap and may have better suggestions in the morning.

[Ballot comment]
I support Alissa's BLOCK comments.

Otherwise, I have some mainly editorial comments:

"  1) Transition Mechanisms and Partial Deployments: The WG will
    describe how BIER can be introduced in existing multicast
    networks to shift multicast delivery either end-to-end or in part
    of a network from mechanisms such as PIM, ng-MVPN, etc."

I can't parse that sentence, especially after "end-to-end". I wonder if two different ideas got merged.

" 3) Use Case:"

I suspect that should be "Use Cases".

"  5) Management models:"

Would it make sense to say "Management data models"? (remembering there are still kinds of models other than yang models :-) )

[Ballot block]
I see in the following text in the current BIER charter:

"As described in
item (9) below, the work may become Standards Track once there
is sufficient experience with the benefits and downsides of the technology.
...
9) Deployment Evaluation: Once there is deployment experience, the
WG will produce an Informational RFC describing the benefits,
problems, and trade-offs for using BIER instead of traditional
multicast forwarding mechanisms. Ideally, this should also contain
an analysis of the impact and benefit of the new BIER data-plane to
the overall Internet architecture. This document is intended to be
used to evaluate whether to recharter BIER to produce Standards
Track RFCs."

Has the WG produced this RFC? I see draft-shepherd-bier-standards-track, but that is an individual draft. If the RFC hasn't been produced, it seems like the WG hasn't met the conditions set out in the current charter to include standards track work in the recharter.

[Ballot block]
While a Discuss, this should be simple to address as I think it's a bit of a misnomer
which Alvaro has already noted.
About:
"8) BIER Traffic Engineering: Definition of an architecture, and
  specification of the associated technology, for a BIER-based
  mechanism to support traffic engineering."

Looking at the wg draft (which it seems this new charter item is based on),
the draft says:
"It does support traffic engineering by explicit hop-by-hop forwarding"
and "it is more similar to SR than RSVP-TE".

So it is not TE, it is explicit forwarding. As Alvaro noted, this should not
be identified in the charter as TE. I don't see any need for this new item to
be in the charter (as Alvaro noted).

This is a Discuss because if this is not a simple misnomer, then this work
clashes with TEAS. TEAS is chartered and responsible for "Traffic-engineering
architectures for generic applicability across packet and non-packet networks.
This includes both networks that include the use of PCE and those that do not."

[Ballot block]
-
  5) Management models: The WG may work on YANG models to manage BIER.

"May work", really?  A new protocol without automation doesn't exist.
And there is already draft-ietf-bier-bier-yang-03
What do I miss? Or maybe it's just a wording issue?

[Ballot comment]
-
OLD:
The BIER-WG is now chartered to produce Standards Track RFCs, including
RFCs 8279 and 8296.

NEW:
The BIER-WG is now chartered to produce Standards Track RFCs, including the update of
RFCs 8279 and 8296.

-
  3) Use Case: The WG will produce one use-case document that clearly
    articulates the potential benefits of BIER for different use-cases.

You already have your architecture and protocol. So I guess there are use-cases.
Should this be called an applicability document?

-
"The BIER-WG will serve as a forum to discuss how BIER can be applied."
Is there a specific goal behind this sentence? Or just normal WG discussions?

[Ballot comment]
Just a couple of nits:

(1) "...as has been done for MVPN."  A reference to draft-ietf-bier-mvpn would be nice.

(2) Item 8 mentions draft-ietf-bier-te-arch.  While the WG has already adopted that draft (and I have no issues with it), I would prefer it if the charter didn't explicitly mention it (or any other document) to allow flexibility...just in case the WG decides on a different direction.  Suggestion:

NEW>
8) BIER Traffic Engineering: Definition of an architecture, and
  specification of the associated technology, for a BIER-based
  mechanism to support traffic engineering.

[Ballot comment]
Most of these observations are attempts at friendly amendments, but I'm really thinking the first one needs help. The existing working group participants may understand that perfectly, but I'm not even close to understanding.

I'm not sure I can parse this text.

    A minimum of the necessary mechanisms
    to support incremental deployment and/or managing
    different BIER mask-length compatibility may be defined.

If I was guessing, I'd guess

    At a minimum, the necessary mechanisms needed to

    o support incremental deployment,
    o manage different BIER mask-length compatibility
    o or both

    may be defined.

but guessing isn't helping me understand clearly. What am I getting wrong?

Unless "non-congruent topologies" is a term of art in this text,

    Operation of BIER in non-congruent topologies, i.e.
    topologies where not all routers are BIER capable can
    also be addressed.

ISTM that

    Operation of BIER in topologies where not all routers
    are BIER capable can also be addressed.

would be clearer. (Since the term is expanded, I assumed it wasn't a term of art)

I think I understand where

    Each such mechanism must include an
    applicability statement to differentiate its necessity from
    other proposed mechanisms.

is headed, but ISTM that as stated, this is combinatorial - every time a new mechanism shows up, all the previously proposed mechanisms must add a statement about differentiation from the new mechanism. I bet that's not what's intended. Perhaps maintaining a separate applicability statement differentiating between all mechanisms would be more tractable?

I note that

8) BIER Traffic Engineering:  An architecture for BIER-TE is defined
    in draft-ietf-bier-te-arch; associated fundamental technology is
    included.

says "is defined", but that draft looks like a -00 that's a couple of weeks old. Would "is being defined" be more accurate? (This is not the usual moan about naming individual drafts as starting points in a new working group)

In

13) Applicability of BIER to Applications: The WG may advise on the
      applicability of BIER to various applications.

is "advise" intended to be some flavor of RFC, or just a "sounds like a plan"/"sounds like a bad idea" e-mail? I don't need to know the answer to that, but the working group might benefit from knowing it.

I wonder if the paragraph about working groups to be coordinated with and advised would be clearer as a bulleted list?

[Ballot comment]
I fully support the formation of this WG.

I think that the requirement for independent and interoperable implementations before the publication of an Experimental RFC is harsh.

[Ballot comment]
I share Pete's thoughts about using a wiki for at least some of the non-protocol work in this charter, with the additional thought that I'd hope some of that work starts way earlier than "after we have deployment experience", which makes perfect sense if you're publishing RFCs but seems to get in the way of starting wiki entries unnecessarily.

But as we seem to to repeat consistently when the IESG has these conversations, there are all kinds of reasons (ranging from good reasons to bad reasons) to publish non-protocol work as RFCs, and the ADs need to do what makes sense for the community they're serving ... just make good choices :-)

[Ballot comment]
I'm not a big fan of specifying in the charter that the WG will "produce a document" for anything that is not protocol, nor do I think it's a good idea to specify the number of particular documents a WG will produce at all: WGs often discover that they should combine or split different pieces of the protocol, and I think that's almost always a management task for the chairs and the WG, not something in the "contract" with the IESG and the rest of the community. For non-protocol documents, it's often turns out better to publish these as an updatable wiki instead of trying to finalize 'the one true RFC', and I certainly wouldn't want to constrain them to an "Informational RFC" in particular. I'm not going to stand in the way if you think that this particular group of folks would best be guided by specifying these things and having them written into the charter, but I did want to voice my concern.

[Ballot comment]

I'm fine with this going for external review.

I would like to see the security properties of Bier called out more
as something that the proposed WG will address, e.g. does the
work to date include any integrity mechanisms so that one could
check if a bit-flip is causing packets to be sent to the "wrong"
places? Is there some (usable) security mechanism in place
for establishing the bit-mask value to use at ingress? Etc.

[Ballot comment]
I am very strongly supportive of this work and appreciate how hard
Alia has driven to get a WG formed and how she has acted to avoid
any further delay.

Balancing this as Experimental *in*the*first*instance* seems to be a
very wise move and to enable us to start the work in earnest. There
are many things that need to be discovered about building and
deploying this technology before we should attempt to publish as
standards track. I believe, however that it may be possible to move
the deliverables to standards track (by rechartering) before
publication as RFC if the experimentation yields results.



That said, I think some of the bars are set too high in this charter.
If everyone is comfortable with them, then I see no issue, but I would
not mind relaxing as follows:

Deliverble 2

  Due to the critical need
  to have a high-quality and stable RFC for a new data-plane
  encapsulation, the MPLS-based encapsulation draft shall wait after
  WGLC and not progress to IETF Last Call until there are two
  independent interoperable implementations.

This seems wholly unnecessary for an Experimental RFC

Deliverable 2

  This draft also shall wait after WGLC
  and not progress to IETF Last Call until there are two independent
  interoperable implementations.

Ditto

Deliverable 9 might better be called "Deployment Evaluation" since many
of the things it calls for are future-looking rather than reports.
Recall that widescale deployment of an experiment is less likely.




Maybe three things missing:

- Multi-domain or not. I don't mind which way you jump, but you should
  jump.

- Consideration of whether extensions to IGPs are experimental (using
  experimental code points) or can access other code points. This
  question was touched on by Eric Rosen on the mailing list. Will the                       
  existing registration policies support this work in a sensible way
  or will soething have to change (the registries or the target status
  of this work)?

- Statement of experimental criteria and objectives. Although
  deliverable 9 hints at these, by placing it at the bottom of the list
  you lose the focus in the protocol desgin phase.

[Ballot comment]
1. The first work item says the WG "will specify the information that is required by a BIER header to support BIER forwarding."  That doesn't parse right to me.  Will the WG specify what information is needed by a router to support BIER forwarding?  Will the WG specify what information is needed in a BIER header?  A little clarification would be good.

2. Work item #2 (non-MPLS data plane) combined with the last paragraph of the charter seems to preclude the WG from looking at the BIER and PIM/IGMP/MLD interactions.  Is that the intent?

3. Does the WG need to develop an Applicability Statement for the non-MPLS data plane, if they choose to move that direction?

4. Does the charter require the WG to publish the use cases document?

[Ballot comment]
One question. This text

  9) Deployment Experience: Once there is deployment experience, the
  WG will produce a document describing the benefits, problems, and
  trade-offs for using BIER instead of traditional multicast
  forwarding mechanisms.  Ideally, this should also contain an
  analysis of the impact and benefit of the new BIER data-plane to
  the overall Internet architecture.  This document is intended to be
  used to evaluate whether to recharter BIER to produce Standards
  Track RFCs.
 
seems like a lot of words to say "once there is deployment experience, BIER may be rechartered to produce Standards Track RFCs". Do you need to define the gates they must pass through now? (What if you think of something else later?)

"produce a document" sounds like we're likely to be having the usual discussion about whether to publish a working paper as an RFC when that happens. If they sent the ADs an e-mail, would that be wrong?

[Ballot comment]
So the size of the bier domain is bounded I suppose by the number of egress points you're willing to include in your header. given the inherent suitability of such a method for overlays it seems like it distinctly bounds the size of such an overlay based on the header size/  if you chain bier domains (no subdomain) how do you do loop detection (or don't you).