Re: [Bier] Robert Wilton's Discuss on draft-ietf-bier-te-arch-10: (with DISCUSS and COMMENT)

[Toerless Eckert <[e-mail]>]

Thanks, Robert

Detailed replies for your comments below inline.
It should resolve all your concerns.
These have been integrated into draft rev -12
which the authors feel is ready for RFC editor.

No diffs resulting from your feedback, but

Full diff from -11 to -12:

http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-11.txt&url2=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-12.txt

Thanks again for your review.

Toerless

On Wed, Aug 25, 2021 at 06:50:54AM -0700, Robert Wilton via Datatracker wrote:
> Robert Wilton has entered the following ballot position for
> draft-ietf-bier-te-arch-10: Discuss
> 
> 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 DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/
> 
> 
> 
> ----------------------------------------------------------------------
> 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 8279.  RFC
> 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.

I think the questions about the intended status (STD) have been answered
by others in the email discussion.

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

Yes. Thanks a lot to Alvaro to help push me to restructure the document
in -10 so this now is clearer. There is a lot of controller complexity when
you want to save bits, which may be fine (controllers are "just" software).

Given how i have seen a lot of SR folks argue that
8 SR steering entries = 8 * 128 = 1024 bits are no deployment/overhead problem, i
would of course advise to keep BIER-TE deployments simple by using such long
bitstrings where needed ;-))

Cheers
    Toerless

> Regards,
> Rob