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

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Sep 2017 17:05:32 -0400

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

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 26 Sep 2017 15:09:09 -0700

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 <[email-masked]> 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.
>
> 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
> "'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
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Sep 2017 15:13:39 -0700

Hi Alia,
thank you for raising the question of proper reference in regard to use of
the OAM field. It is very good to have an opportunity to update BIER WG on
work related to use of the Alternate Marking method in SFC and NVO3. But
first my thought about the reference. We have Performance Measurement with
Marking Method in BIER Layer
<https://datatracker.ietf.org/doc/draft-ietf-bier-pmmm-oam/> where use of
the OAM field is discussed. Perhaps this BIER WG draft could be used as
reference in draft-ietf-bier-mpls-encapsulation in place of draft-chen-ippm-
coloring-based-ipfpm-framework.
And short update with a proposal to change naming. There two drafts that
discuss applicability of the Alternate Marking method (AMM) in SFC and
NVO3. Working on them we've realized that 'Mark' as name of the field to be
used for AMM is more informative than 'OAM'. Hence the proposal to change
the name of OAM field into Mark field.

Regards,
Greg

---

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Sep 2017 18:14:59 -0400

Hi Tony,

> in the shepherd writedown ... This can go in.

Excellent :-)

> 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

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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Sep 2017 18:17:26 -0400

Hi Greg,

Thanks - I went looking at the work in IPPM and not at the drafts in BIER.
>From a quick glance, draft-ietf-bier-pmmm-oam does seem like a better
reference.

Regards,
Alia

On Tue, Sep 26, 2017 at 6:13 PM, Greg Mirsky <[email-masked]> wrote:

> first my thought about the reference. We have Performance Measurement
> with Marking Method in BIER Layer
> reference in draft-ietf-bier-mpls-encapsulation in place of
> draft-chen-ippm-coloring-based-ipfpm-framework.

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 27 Sep 2017 10:34:10 -0400

On 9/26/2017 6:14 PM, Alia Atlas wrote:
> I believe that we do need to explicitly request an EtherType in this 
> document. 

In that case, someone will need to provide the necessary text, and say 
where exactly to put it.

Unless there's a BCP that says how to request an ethertype in an 
internet-draft, in which case perhaps someone could send a pointer to it.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Sep 2017 10:52:28 -0400

[cc'ing Pat & Russ for their opinions on the right way to document the need
for a new EtherType]

> internet-draft, in which case perhaps someone could send a pointer to it.

The reference is to RFC 7241, which describes the formal relationship
between IEEE 802 and IETF.

In the section where an EtherType is needed, specify that the non-MPLS
encapsulation uses EtherType TBA1.
Add a section after the IANA considerations that says:

"To support this standard, the IESG and IETF request the allocation of an
EtherType TBA1 to be used for the BIER non-MPLS encapsulation. "

It would be helpful to also include Tony's text from earlier about why
using a sub-type isn't useful - so that the IEEE expert can easily find
that.

Thanks,
Alia

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 27 Sep 2017 08:29:33 -0700

Here's the text I fired off to Alia and was bonvolently received by IEEE
with the comment of "look us up again when you have an RFC"

---

“We would like to request a distinct IEEE Ethernet Type for the use of the
draft

      https://datatracker.ietf.org/doc/draft-ietf-bier-mpls-encapsulation/

which defines an encapsulation for BIER technology that can be either
carried natively as MPLS frames or the same way MPLS is carried over
Ethernet in types 0x8847 and 0x8848. Major reasons why we would like to
avoid using existing types or a subtype field are

a)      The BIER header is carefully aligned  for fast processing being at
the same point in the networking stack as native MPLS (sometimes
colloquially called level 2.5). It is a carrier backbone targeted
technology where forwarding speed requirements are the highest. Fast
silicon can easily strip today Ethernet II headers to provide an aligned
structure and adding subtype field would present unnecessary practical
difficulty in implementation of the technology.

b)      Albeit it would be thinkable that 0x8847 or 0x8848 types could be
used directly to carry the BIER encapsulation relying on the fact that BIER
also presents a “label” equivalent, we do perceive that such a route would
be very perilous since the label  MUST be presented in the same place in
the payload (which BIER encapsulation today does not) and even then,
intermediate hops may not be able to tell whether the label presents a BIER
encapsulation or an MPLS label stack.

c)      BIER header carries in front today a well defined nibble value that
allows silicon that “peeks” behind ether frame or MPLS label stack without
understanding the payload precisely to avoid interpreting BIER as IPv4 or
IPv6 frame and build 5-tuple spurious entropy that way. Albeit such a
behavior is questionable, it is widely deployed in today’s vendors’ silicon
chips to distinguish “flows” behind MPLS and unknown frames. Adding subtype
field will misalign this field and may lead to unforeseen results.

d)      No obvious candidate Ethernet Type to “subtype” BIER into is
discernible

“
---

--- tony

On Wed, Sep 27, 2017 at 7:52 AM, Alia Atlas <[email-masked]> wrote:

> [cc'ing Pat & Russ for their opinions on the right way to document the
> need for a new EtherType]
>

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 27 Sep 2017 13:40:08 -0400

> I believe that we do need to explicitly request an EtherType in this 

Let me ask one more time whether we really want to do this.  If we do, 
the document's publication will be held up until the ethertype gets 
assigned.  If the IEEE decides not to assign an ethertype, the document 
will never get published (at least, not without additional process).  
That's why the document says that the specification of a layer 2 
codepoint for non-MPLS BIER is outside the scope of the document.  We 
really shouldn't gate the publication of the document on non-IETF 
process/politics.

RFC 7241 does not seem to provide a procedure in which an RFC explicitly 
makes a request of the IEEE.

If we do put an "IEEE Considerations" section in the document, to 
request the ethertype, I don't think it's appropriate to include Tony's 
text arguing that we don't want to use subtypes.  If an ethertype gets 
assigned, that all becomes irrelevant.  Tony's text is a good 
stand-alone message that can be sent to IEEE after the document is 
approved by IESG.

On the issue of the OAM bits, I suggest the following text for section 
2.1.2:

    OAM:

       By default, these two bits are set to zero by the BFIR, and are
       not modified by other BFRs.  These two bits have no effect on the
       path taken by a BIER packet, and have no effect on the the quality
       of service applied to a BIER packet.

       The use of these bits in other than the default manner is
       OPTIONAL.  Specification of the non-default use or uses of these
       bits is outside the scope of this document.  (See [BIER-PMM] for
       an example of such a specification.)

This makes it clear that the reference to BIER-PMM 
(draft-ietf-bier-pmmm-oam) is non-normative.

I didn't add anything about keeping counts of consecutive packets with 
the OAM bits set.  That really requires a more detailed specification 
(consecutive packets with the same entropy?  with the same BitString?  
with the same payload header?) and I think we want to keep the OAM 
specification in a separate document.

I don't think it is wise to change the name of the "OAM bits" to the 
"Mark bits".  That will cause a problem if for some reason the bier-pmmm 
draft fails to advance.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Sep 2017 13:47:27 -0400

On Wed, Sep 27, 2017 at 1:40 PM, Eric C Rosen <[email-masked]> wrote:

> Let me ask one more time whether we really want to do this.  If we do, the
> document's publication will be held up until the ethertype gets assigned.
> If the IEEE decides not to assign an ethertype, the document will never get
> published (at least, not without additional process).  That's why the
> document says that the specification of a layer 2 codepoint for non-MPLS
> BIER is outside the scope of the document.  We really shouldn't gate the
> publication of the document on non-IETF process/politics.
>
> If we do put an "IEEE Considerations" section in the document, to request
> the ethertype, I don't think it's appropriate to include Tony's text
> arguing that we don't want to use subtypes.  If an ethertype gets assigned,
> that all becomes irrelevant.  Tony's text is a good stand-alone message
> that can be sent to IEEE after the document is approved by IESG.
>

I am fine with sending Tony's text separately.
I am not concerned about the speed at which the IEEE will respond for this
EtherType request. I am not concerned about asking the IESG to make a
request. I have been through the process of getting an EtherType before.
We have an excellent relationship with IEEE 802.1 and I expect that this
will go smoothly and not slow things down.
The worst-case response time is 3 months.

> I didn't add anything about keeping counts of consecutive packets with the
> OAM bits set.  That really requires a more detailed specification
> (consecutive packets with the same entropy?  with the same BitString?  with
> the same payload header?) and I think we want to keep the OAM specification
> in a separate document.
>
> I don't think it is wise to change the name of the "OAM bits" to the "Mark
> bits".  That will cause a problem if for some reason the bier-pmmm draft
> fails to advance.
>

This text looks good to me.

Thanks,
Alia

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 30 Sep 2017 02:28:44 +0000

Hi all,

I wonder whether it would be better to move the non-MPLS encapsulation part to draft-wijnandsxu-bier-non-mpls-bift-encoding-00.txt or a totally new draft. In this way, there is no need to worry about the assignment of a new EtherType for the non-MPLS BIER header anymore when publishing this draft, and the draft content is now align with the draft title again.

Best regards,
Xiaohu

发件人: BIER [mailto:[email-masked]] 代表 Alia Atlas
发送时间: 2017年9月27日 6:15
收件人: Tony Przygienda
抄送: [email-masked]; [email-masked]
主题: Re: [Bier] AD review of draft-ietf-bier-mpls-encapsulation-08

Hi Tony,

On Tue, Sep 26, 2017 at 6:09 PM, Tony Przygienda <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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:

Regards,
Alia

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 30 Sep 2017 02:35:29 +0000

s/align/aligned

发件人: BIER [mailto:[email-masked]] 代表 Xuxiaohu
发送时间: 2017年9月30日 10:29
收件人: Alia Atlas; Tony Przygienda
抄送: [email-masked]; [email-masked]
主题: [Bier] 答复: AD review of draft-ietf-bier-mpls-encapsulation-08

Hi all,

Best regards,
Xiaohu

发件人: BIER [mailto:[email-masked]] 代表 Alia Atlas
发送时间: 2017年9月27日 6:15
收件人: Tony Przygienda
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [Bier] AD review of draft-ietf-bier-mpls-encapsulation-08

Hi Tony,

Excellent :-)

Regards,
Alia

--- tony

Major:

Nit:

Regards,
Alia