Re: [Bier] AD review of draft-ietf-bier-mpls-encapsulation-08

There is a -09 version pending where Eric already took care of all my nits
in the shepherd writedown ... This can go in.

My only observation here is that I'm confused ;-) since I assumed the
EtherType is gated on architecture RFC and nothing else but if we want to
request EtherType in this doc specifically I'm fine as well of course ...

--- tony

On Tue, Sep 26, 2017 at 2:05 PM, Alia Atlas <akatlas@gmail.com> wrote:

> As is customary, I have done my AD review of draft-ietf-bier-mpls-encapsulation-08.
> First, I would like to thank the authors & editors, Ice, Eric, Andrew,
> Jeff, Sam, and Israel, as well as the WG for this solid document.
>
> I do have a couple major issues that need to be resolved ASAP so I can get
> this document into IETF Last Call and scheduled for the telechat on Oct 26.
>
> Major:
>
> 1) First, this draft references draft-chen-ippm-coloring-based-ipfpm-framework-06
> for the only description of how the OAM bits are used.  I think, based on a
> very quick scan, that perhaps
> draft-ietf-ippm-alt-mark-10 would work as well - but even that is
> Experimental so would be a downref when this goes Standards Track.   What
> might be useful to say in this draft is:
>
> "'Specifying the values of the OAM bits or interpreting them is not done
> by the BIER forwarding layer. Instead, an OAM layer can specify the value
> to be used by a BFIR and process the received OAM values at a BFER.   The
> OAM bits MAY be set to any value by a BFIR; the OAM bits SHOULD NOT be
> modified by BFRs as part of normal processing, unless instructed to by an
> OAM process. The BFERs SHOULD provide a mechanism for reporting at least
> the number of packets received in a row with each value.  One example of
> how such OAM bits can be used by different OAM processing is described in
> [draft-ietf-ippm-alt-mark]."
>
> I'm sure it can be wordsmithed better.  The key points are to define where
> the OAM bits can be set, where they can be modified, and that packets
> counts based on the values should be provided in some fashion.  Then the
> reference to what the OAM layer does can be informative.  Regardless of the
> reference type, this type of normative language is needed.
>
> 2) In Sec 2.2.3, it says: "Rather, a new ethertype would have to be
> assigned and
>    used.  Specification of the layer 2 codepoints to be used for the
>    non-MPLS BIER encapsulation is outside the scope of this document."
>
> I thought that this document is asking for a standard EtherType for the
> non-MPLS BIER encapsulation??  Certainly, I need text like that to request
> the allocation from IEEE.
> Please be clear that this document is asking for an IEEE Ethertype to be
> allocated,
> if that is, as I understood, the WG's intent.
>
> Nit:
> a) Sec 3 bullet 6a:  s/BFIR's BFIR-id/BFIR's BFR-id
>
> Regards,
> Alia
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>