Subject: [Bier] draft-ietf-bier-ospfv3-extensions-02.txt review with comments/suggestions

From: Toerless Eckert <[email-masked]>
Date: Fri, 20 Nov 2020 07:33:43 +0100

Hi folks

Would certainly like to help move documents along, and so i've 
reviewed subject document. Hopefully this is helpfull:

I have not followed the history of the document, i should probably
apologize for that, but then again, the document itself does not
have a changelog (mumble), so i think we're even.

a) Looking through the diffs and ending up in:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/rfc/rfc8444.txt&url2=https://tools.ietf.org/id/draft-ietf-bier-ospfv3-extensions-02.txt

It looks as if the document is ever more approaching to be
textually identical to it's 'predecesor' (RFC8444). Yet, there is
a gratuitous amount of differences in the text that is just language
and not actual functional difference. 80% of it might be better english,
20% probably not. I wonder if these differences are worth it. I would
imagine that IESG review could be sped up if the diff was minimal and
only covered actual functional differences. However bad the text of
RFC8444 might have been, it DID pass through IESG review and became
standard RFC, so why try to reinvent the language wheel unnecessarily.
One option to resolve this is to simply do take the whole of RFC8444
and just put in the minimal text diffs required to make it about OSPFv3.

b) Functionally, i really would love to see a short summary sentence about
the functional difference between BIER for OSPFv2 (RFC8444) and OSPFv3. If
i correctly understand it, there is no difference whatsoever in
functionality for BIER except that by virtue of the OSPF version,
OSPFv3 allows for BFR-prefixes to now be either IPv4 and/or IPv6 addrsses.
Right ? Saying that would be a helpfull sentence.

c) Wrt to the inter area propagation described in 2.3:

I never understood from RFC8444 2.3 and from this draft, whether the
described ABR propagation procedure was an optional ABR configured
policy or whether it must always happen. It would be great for
the text to be clearer about that than it (and RFC8444) currently
is. This may be obvious to OSPF experts, but hey: this is in BIER-WG.

Once i know whether it is always mandatory or configured policy i would
be happy to suggest text that would make that choice clearer to me and
maybe other non OSPF experts.

In summary, pending on resolution of b), c), i think the document
is ready to be passed to IESG. IMHO, a) is an RFC-editor question and
if i was shepherd i would try to make that argument with IESG if
you folks want to keep these a) "textual improvements" over RFC8444.

Cheers
    Toerless

On Sun, May 24, 2020 at 06:57:03AM -0700, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF.
> 
>         Title           : OSPFv3 Extensions for BIER
>         Authors         : Peter Psenak
>                           Nagendra Kumar Nainar
>                           IJsbrand Wijnands
> 	Filename        : draft-ietf-bier-ospfv3-extensions-02.txt
> 	Pages           : 10
> 	Date            : 2020-05-24
> 
> Abstract:
>    Bit Index Explicit Replication (BIER) is an architecture that
>    provides multicast forwarding through a "BIER domain" without
>    requiring intermediate routers to maintain multicast related per-flow
>    state.  Neither does BIER require an explicit tree-building protocol
>    for its operation.  A multicast data packet enters a BIER domain at a
>    "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at
>    one or more "Bit-Forwarding Egress Routers" (BFERs).  The BFIR router
>    adds a BIER header to the packet.  Such header contains a bit-string
>    in which each bit represents exactly one BFER to forward the packet
>    to.  The set of BFERs to which the multicast packet needs to be
>    forwarded is expressed by the according set of bits set in BIER
>    packet header.
> 
>    This document describes the OSPFv3 [RFC8362] protocol extensions
>    required for BIER with MPLS encapsulation [RFC8296].  Support for
>    other encapsulation types is outside the scope of this document.  The
>    use of multiple encapsulation types is outside the scope of this
>    document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bier-ospfv3-extensions/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bier-ospfv3-extensions-02
> https://datatracker.ietf.org/doc/html/draft-ietf-bier-ospfv3-extensions-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-ospfv3-extensions-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 20 Nov 2020 07:39:54 +0100

Oh, and of course once i hit the "send" button, one more issue comes up:

Given how this draft does now at least looks as if it was cloned & modified
from RFC8444 (even if that may not have been its history of evolution),
i think it will be highly recommended to get statements from the authors
of RFC8444 who are not listed in this draft that they actually PREFER not to be
namd as authors on this draft. Otherwise i think common rules of
cloning, curtesy and the like would mandate that they are listed as
authors (i think... but thats just my logic. I can not pull an RFC
out that would say so).

Even if these RFC8444 authors do NOT want to be named again as
co-authors, i would also suggest to ask them for IPR disclosure during
shepherd step.

Cheers
    Toerless

-- 
---
[email-masked]