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

Hi Tony,

On Tue, Sep 26, 2017 at 6:09 PM, Tony Przygienda <tonysietf@gmail.com>
wrote:

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

Excellent :-)

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

I believe that we do need to explicity request an EtherType in this
document.  The architecture draft doesn't mention Ethertype at all - and
the details of the encapsulation and reasoning for needing it are in this
document - except for the "out of scope"' part.

Regards,
Alia

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