Subject: [Bier] Benoit Claise's No Objection on draft-ietf-bier-architecture-08: (with COMMENT)

From: Benoit Claise <[email-masked]>
Date: Wed, 13 Sep 2017 08:34:02 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-bier-architecture-08: 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.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Next point moved from DISCUSS to COMMENT after the IESG telechat:
1. I want to come back to the experimental status.

I have seen Alia's reply:

    In the BIER Charter, work item 9 describes a document based on deployment
    experience that can justify moving the BIER work from Experimental to
    Standards Track.  When I chartered the WG, it wasn't clear whether it was
    merely a good idea or a good idea with enough motivations towards
    deployment that it is worth complicating the architecture at the narrow
    point of the IP hourglass.

>From the writeup, it seems that the experiment is successful already:

    The vendors are being quite tight lipped about current implementations.
    Operator feedback indicates there are at least two implementations
    currently, with others in the works. There are currently five vendors
    collaborating on the work in the IETF.

However, I've not been following the specifications development and
implementation to provide a definitive answer.

At the minimum, the document needs to describe what the criteria are for a
successful experiment.
    Implementations (RFC7942?)?
    two interop implementations?
    hardware implementation?
    "deployment experience" (to cite the charter text)?
    impact analysis?
    something else?

The ideal BIER document for this explanation is this architecture doc.
A reference to the charter Item 9 would be a good start.

Examples:
https://tools.ietf.org/html/rfc7360#section-1.3
https://tools.ietf.org/html/rfc7499#section-2

-   Each BFR MUST be assigned a single "BFR-Prefix" for each sub-domain
   to which it belongs.  A BFR's BFR-Prefix MUST be an IP address
   (either IPv4 or IPv6) of the BFR.  It is RECOMMENDED that the
   BFR-prefix be a loopback address of the BFR.

Just one observation. Was thinking, so it's like an (OSPF) routerId, except
that it's called a prefix. Then I understood, reading further. It's not called
a routerId because this address/prefix must be routable

- Was wondering. Is this mechanism only for multicast packets? What about
anycast/unicast? Some multicast packets would take BIER encap, while others
packets would take a different encap From a troubleshooting point of view, does
it make sense (is it even allowed) to send non multicast traffic over BIER.