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

From: Xiejingrong <[email-masked]>
Date: Thu, 28 Sep 2017 13:29:29 +0000

In chap 2.1.1.1, there is a description:
“The BIER-MPLS labels are locally significant (i.e., unique only to the BFR that advertises them) downstream-assigned MPLS labels.”

I have a question: Why BIER-MPLS labels must be downstream-assigned MPLS labels ?
Althrough in current BIER using IGP ,  MPLS labels to (SD, SI, BSL) are downstream-assigned, BUT there may be other Possibility, for example when considering use a controller.
I advice remove this limit, or describe this limit as a case of using IGP.

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

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: Thu, 28 Sep 2017 09:23:07 -0700

As we found out over time a label is a 20bit number that can be used as
pivoting point for all kind of decisions (SPRING, unified SR or a SID, or a
value that reboots the silicon ;-) so this is a fair observation. Let me
react to that:

Generally, BIER is laid out broadly enough _anything_ can install BIFTs and
for that matter incoming "bindings" for (SD,SI,BML), controller, IGPs,
static config. So all those encaps & binding drafts are just incarnations
of different ways to get the forwarding state into the nodes. IGP
downstream being most interesting one for initial deployments.

MPLS is a "label switching" architecture so it deals with labels being
locally significant for better or for worse. So the draft is logically
consistent. The labels _are_ locally significant in BIER and have to be for
MPLS since we have to deal with all kind of vast MPLS ecosystem such as
0x8847/8, MPLS in UDP and so on. All that can carry MPLS BIER.

Nothing will prevent the encapsulation from working in a different way,
i.e. a box does not allocate local labels but gets the binding including
all the downstream labels from something else than IGP, static, controller,
or magic. I don't consider that particularly practical except for maybe
very few, static "trees" but time will tell.

The most extreme version of that is something like a global SID which is
basically described in
https://datatracker.ietf.org/doc/draft-wijnandsxu-bier-non-mpls-bift-encoding/?include_text=1.
Strictly speaking this is indistinguishable from all the boxes _by chance_
having allocated all the same label or having those labels statically
synchronized and with that the MPLS encapsulation could be "abused" that
way or rather, it's one of the extreme points in the spectrum it covers.

In short, I think the draft is consistent in the "MPLS section" and allows
non-locally significant (or whatever scope is chosen) labels in non-MPLS
part with the tactic understanding that you _could_ use MPLS in the style
of
https://datatracker.ietf.org/doc/draft-wijnandsxu-bier-non-mpls-bift-encoding/?include_text=1
whereas
all the unintended consequences of that are yours and yours alone ;-)

--- tony

On Thu, Sep 28, 2017 at 6:29 AM, Xiejingrong <[email-masked]> wrote:

> “The BIER-MPLS labels are locally significant (i.e., unique only to the
> BFR that advertises them) downstream-assigned MPLS labels.”
>
>
>
> Althrough in current BIER using IGP ,  MPLS labels to (SD, SI, BSL) are
> downstream-assigned, BUT there may be other Possibility, for example when
> considering use a controller.
>
> *发件人:* BIER [mailto:[email-masked]] *代表 *Alia Atlas
> *发送时间:* 2017年9月27日 5:06
> *收件人:* [email-masked]; [email-masked]
> *主题:* [Bier] AD review of draft-ietf-bier-mpls-encapsulation-08
>
>
>
> 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.
>
>
>
> 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.
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>