Subject: Genart last call review of draft-ietf-bier-architecture-07

From: Dan Romascanu <[email-masked]>
Date: Sun, 25 Jun 2017 03:54:07 -0700

Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bier-architecture-??
Reviewer: Dan Romascanu
Review Date: 2017-06-25
IETF LC End Date: 2017-06-29
IESG Telechat date: 2017-07-06

Summary:

This document specifies a new architecture known as "Bit Index Explicit
Replication" (BIER) for the forwarding of multicast data packets through a
"multicast domain".  It does not require a protocol for explicitly building
multicast distribution trees, nor does it require intermediate nodes to
maintain any per-flow state. This architecture is .  While the Abstract and
Introduction of the document mentions Architecture as the principal scope, this
document goes well beyond the scope of a typical architectural document.
including detailed definitions of the procedures, terminology and normative
algorithms required for BIER.

The document is clear and detailed. Because of its structure, I am missing some
information that usually can be found in architecture documents. I included
these in the 'minor issues' list. Although none of these may be a show-stopper,
I believe that addressing these before document approval can improve the
quality of the document and of the overall BIER work.

Major issues:

Minor issues:

1. As the document is targeting 'Experimental' it would be useful to mention
what is the scope of the experiment. The charter actually says:

' The scope of the experiment will be
documented in the output of the Working Group.'

Would not the Architecture document be the right place for this? If not, is
there another document that deals or is planned to define the scope of the
experiment?

2. While the Abstract and Introduction of the document mentions Architecture as
the principal scope, this document is different from a typical architectural
document. While it defines well the procedures, terminology and normative
algorithms required for BIER Intra-domain forwarding, it goes well beyond the
level of detail that other similar documents go. Specifications of the
procedures and normative algorithm should be mentioned in Abstract and
Introduction, they occupy the same or more space than architecture.

3. On the other hand I am missing the relationship with other work items in the
BIER charter - there is no manageability section for example, there is no
reference to the performance impact in networks. Maybe these are dealt with in
a different document or documents or BIER, if so it would be good at least to
mention and reference these here.

4. I also would have expected the architecture document to refer the use cases
document and note which of the use cases are being addressed and how -
draft-ietf-bier-use-cases is not even included in the references.

5. Sections 3 to 6 mentioned repeatedly provisioning. As there is no Operations
and Manageability section as in many other Routing Area documents, it is not
clear how this is expected to happen. For example draft-ietf-bier-bier-yang is
not mentioned or referred. I suggest adding a note (and maybe references) for
clarity.

6. In section 8 I found:

'Every BFR must be provisioned to know which of its interfaces lead to
   a BIER domain and which do not.  If two interfaces lead to different
   BIER domains, the BFR must be provisioned to know that those two
   interfaces lead to different BIER domains. '

It seems that the two 'must' in these sentences would rather be capitalized.

Nits/editorial comments:

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 27 Jun 2017 10:42:17 -0400

On 6/25/2017 6:54 AM, Dan Romascanu wrote:
> what is the scope of the experiment.The charter actually says:
>

I don't really know what is meant by "the experiment" or "scope of the 
experiment", but I'm pretty sure it is not relevant to the architecture 
(or to the forwarding rules).

I don't know if there is another document discussing "scope of the 
experiment", or if such a document is actually needed.  That would be a 
question for the WG chairs.

> Introduction, they occupy the same or more space than architecture.

I can add a few sentences to the abstract and introduction to make it 
clear that the procedures for fowarding BIER packets within a BIER 
domain specified in this document.

> mention and reference these here.

There is no requirement to include a manageability section.

I believe there is ongoing work having to do with Operations and 
Management of BIER, but as that does not help to understand the 
architecture (or forwarding procedures), I don't think it would be 
appropriate to reference that work.

With regard to the performance impact, if the question is speed of 
forwarding, there is mention of the fact that the number of lookups 
needed to forward a BIER packet is on the order of the number of 
neighbors.   I don't know what else can really be said at this level of 
detail, as the actual forwarding performance will depend a great deal on 
the implementation.  I'm not worried too much about that, because if 
BIER implementations do not perform well, the technology will not catch on.

> draft-ietf-bier-use-cases is not even included in the references.

I don't see any reason why the architecture document should reference 
the "use cases" document.  An explanation of how to apply the 
architecture to each use case is not within the scope of the 
architecture document.

> clear how this is expected to happen.

How OAM is "expected to happen" would be outside the scope of this 
document.

> For example draft-ietf-bier-bier-yang is

I don't see any reason to reference that document.

> It seems that the two 'must' in these sentences would rather be capitalized.

I will make that change.

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 29 Jun 2017 08:45:50 -0700

I picked up shepherd of this doc. Will reply by end of week to Dan's,
Eric's comments ...

thanks

-- tony

On Tue, Jun 27, 2017 at 7:42 AM, Eric C Rosen <[email-masked]> wrote:

> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> experiment", but I'm pretty sure it is not relevant to the architecture (or
> to the forwarding rules).
>
> clear that the procedures for fowarding BIER packets within a BIER domain
> specified in this document.
>
> forwarding, there is mention of the fact that the number of lookups needed
> to forward a BIER packet is on the order of the number of neighbors.   I
> don't know what else can really be said at this level of detail, as the
> actual forwarding performance will depend a great deal on the
> implementation.  I'm not worried too much about that, because if BIER
> implementations do not perform well, the technology will not catch on.
>
> I don't see any reason why the architecture document should reference the
> "use cases" document.  An explanation of how to apply the architecture to
> each use case is not within the scope of the architecture document.
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 29 Jun 2017 12:42:18 -0700

Dan, thanks for your comment. My comments inline and I encourage the
working group to provide comments.

> question for the WG chairs.
 Applicability statements we have in the charter as #4 and it is probably a
more natural place to document the scope but I consider it unrelated to the
architecture draft.

> specified in this document.

The abstract is already pretty fat, let's keep the additions trim.
Introduction of course can benefit from adding quick overview of introduced
procedures and algorithms.

> appropriate to reference that work.

Yes, OAM is in charter & document for it exists. I see nothing wrong with
referencing it but I don't think it needs a manageability section.

> implementations do not perform well, the technology will not catch on.

agreed. I would suggest actually to point out that the algorithm in the
architecture is not normative. The architecture leaves a lot of leeway in
terms how efficient the algorithm can be in terms of reducing replication
vs. speed vs. e.g. ECMP sophistication. This is intended.

As Eric says, if the turbine will be underpowered, this suidae will not
leave the ground ;-)

> each use case is not within the scope of the architecture document.

I see no harm in referencing use cases but not much use for it either
except showing that the architecture is flexible enough to meet wide range
of applications.

> How OAM is "expected to happen" would be outside the scope of this

The "provisioning" language is unfortunate. We could (and maybe should)
replace it simply with "MUST support" rather than "be able to be
provisioned" and be done. Whether it's a controller, IGP signalling or
anything else is irrelevant to BIER architecture.

> I don't see any reason to reference that document.

I agree, I don't think Yang is needed/helpful in an architecture document.

---

From: Dan Romascanu <[email-masked]>
Date: Thu, 29 Jun 2017 23:20:10 +0300

Just a short clarification on one point (or two).

See in text.

Regards,

Dan

> anything else is irrelevant to BIER architecture.

Please make a distinction between Operations and Management, and OAM
(Operations, Administration, Maintenance) as per RFC 6291. OAM is just one
of the aspects of Operations and Management.

While a dedicated section on Operations and Manageability considerations is
not mandatory, it is part of many documents in the Routing Area. I hold the
opinion that from operators perspective operational and manageability
aspects are core and should be dealt with in architecture and protocol
documents. Of course, as Gen-ART comments are written for the benefit of
the IESG and especially for the IETF chair, it's up to them to consider or
discard these comments. Note also that I marked them as 'minor' so they are
not show-stoppers IMO.

Regards,