Subject: [Bier] Spencer Dawkins' No Objection on charter-ietf-bier-01-01: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Fri, 09 Feb 2018 10:04:50 -0800

Spencer Dawkins has entered the following ballot position for
charter-ietf-bier-01-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-bier/

----------------------------------------------------------------------
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?

---

From: Alia Atlas <[email-masked]>
Date: Fri, 9 Feb 2018 14:55:01 -0500

Hi Spencer,

Thanks for the detailed review, suggestions & comments.
As always, detailed responses are in-line.

> https://datatracker.ietf.org/doc/charter-ietf-bier/

Perhaps

"Mechanisms to support incremental deployment and/or manage
different BIER mask-length capabilities may be defined.  The number of
different mechanisms should be minimized."

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

The congruency is  in reference to the complete IGP topology.  Agreed on
your
simplification.

> all mechanisms would be more tractable?

"from previously adopted mechanisms" ?   I'm looking for why an operator
would use a
particular one and why the WG needs to standardize it. I don't think we're
at the separate
applicability statement for differentiation; we're not near an explosion of
them yet.

Given all of the above & rereading that paragraph on Transition Mechanisms,
what about
replacing that paragraph with:

"
   Transition Mechanisms: 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. Mechanisms to support incremental deployment may be
   defined.  Mechanisms that manage different BIER mask-length support
   in the network may be defined.  Such mechanisms may consider approaches
   beyond tunneling solutions.  The number of different mechanisms should be
   minimized and each new mechanism should include an applicability
statement
   that clearly describes its utility and distinctions from already
standardized mechanisms.
"

I note that
> about naming individual drafts as starting points in a new working group)

Yes - it was an individual draft for 3 years that was heavily discussed-
but not
in the initial charter scope. It has a lot of support & the WG adopted it
based
on our plan to recharter (and thus reference it not as an individual draft).

I'm happy to add being defined.

In
> but the working group might benefit from knowing it.

It can be informational RFCs or coordinating with other WGs.  For instance,
there
is discussion about HTTP caching using BIER for distribution.  There's a
use-case
about it in the use-case draft and discussion at the previous IETF.

For different applications, the right answer will be different - but no
standards track
without AD agreement feels like the riht balance.

> advised would be clearer as a bulleted list?

Sure - it does go on a bit...

I'll make changes on your ack.

Thanks!
Alia