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

From: Xiejingrong <[email-masked]>
Date: Fri, 29 Sep 2017 12:29:31 +0000

Yes, MPLS is MP-Label-Switch, and MPLS-Labels are traditional downstream-assigned and locally.
But, one example, draft-ietf-bier-mvpn-07 define BIER used in MVPN, and use an upstream-assigned MPLS-Label as VPN-label.
Does it implied the upstream-assigned label is also REAL MPLS ?

Another example, draft-ietf-bier-mpls-encapsulation-09 add chap 5, and it says "IEEE has been requested to assign ethertype TBD1 for non-MPLS BIER packets".
Upstream-assigned labels with a precursor context-label, also use a Eth with old ethertype 0x8847.
How should we differ 'MPLS networks' and 'Non-MPLS Networks' in this draft ?

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

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]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>] 代表 Alia Atlas
发送时间: 2017年9月27日 5:06
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[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

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

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 29 Sep 2017 10:20:02 -0400

On 9/29/2017 8:29 AM, Xiejingrong wrote:
> But, one example, draft-ietf-bier-mvpn-07 define BIER used in MVPN, 
> and use an upstream-assigned MPLS-Label as VPN-label.
>

The upstream-assigned label used in bier-mvpn  is not the BIER-MPLS 
label, it is part of the BIER payload.   The upstream-assigned label is 
not interpreted by the BIER layer, and has no impact on the BIER 
forwarding process.  It belongs to the MVPN overlay layer.

> Another example, draft-ietf-bier-mpls-encapsulation-09 add chap 5, and 
> it says "IEEE has been requested to assign ethertype TBD1 for non-MPLS 
> BIER packets".
>

When using the non-MPLS encapsulation, the ethertype would NOT be 
0x8847, but rather some new value to be assigned by IEEE.

To get back to your original question ...

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

This document is about the dataplane, so we need to look at this from 
the dataplane perspective.

In the dataplane, it doesn't really  matter what procedure was used to 
bind the label, all that matter is what procedure you use to look up the 
label.

Suppose the mpls encapsulation is being used.  When a router first 
receives a BIER packet, it appears to be an ordinary MPLS packet. The 
router does not know  that it is a BIER packet until after it looks up 
the top label.  Therefore the BIER-MPLS label must be looked up in the 
same label space that the router would use for looking up the top label 
in any other MPLS packet it receives. There is no special "BIER context" 
that can be derived before looking up the top label, so it cannot be in 
a context-specific label space.

In the case of an "upstream-assigned label with a precursor 
context-label and an ethertype of 0x8847", the context-label is treated 
as "downstream-assigned", in that it is looked up in the ordinary MPLS 
table.  The upstream-assigned label following it would then be looked up 
in the MPLS label table that is identified by
context label.

If the BIER-MPLS labels were assigned and distributed by a controller, 
the routers would still need to do the lookups in the ordinary MPLS 
label table (not a context-specific table), and hence the labels would 
still function in the dataplane as downstream-assigned labels.

With ten years of hindsight, one can see that RFC 5331 should have made 
a clearer distinction between (a) who binds the label and propagates the 
binding, and (b) which MPLS table is used for the look up.

---

From: Xiejingrong <[email-masked]>
Date: Sat, 30 Sep 2017 02:41:30 +0000

Hi, Tony and Rosen,
Thanks a lot for answering my question in detail. I still have some concern:
Suppose 1 SD, 64bit BSL, with a 65536 BFERs, then every router will consume 1024 per-platform downstream-assigned labels. how about 256 SDs then ?
If replaced with one Per-SD Per-router 1 context-label and 1024 upstream-assigned BIER-label, then per-platform Labels will saved and allocing BIER-label will be easy.
Bier-mvpn begin using upstream-assigned label. Need open the door more ?

发件人: Eric C Rosen [mailto:[email-masked]]
发送时间: 2017年9月29日 22:20
收件人: Xiejingrong <[email-masked]>; Tony Przygienda <[email-masked]>
抄送: Alia Atlas <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [Bier] AD review of draft-ietf-bier-mpls-encapsulation-08

The upstream-assigned label used in bier-mvpn  is not the BIER-MPLS label, it is part of the BIER payload.   The upstream-assigned label is not interpreted by the BIER layer, and has no impact on the BIER forwarding process.  It belongs to the MVPN overlay layer.

When using the non-MPLS encapsulation, the ethertype would NOT be 0x8847, but rather some new value to be assigned by IEEE.

I have a question: Why BIER-MPLS labels must be downstream-assigned MPLS labels ?
Although 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.

This document is about the dataplane, so we need to look at this from the dataplane perspective.

In the dataplane, it doesn't really  matter what procedure was used to bind the label, all that matter is what procedure you use to look up the label.

Suppose the mpls encapsulation is being used.  When a router first receives a BIER packet, it appears to be an ordinary MPLS packet.  The router does not know  that it is a BIER packet until after it looks up the top label.  Therefore the BIER-MPLS label must be looked up in the same label space that the router would use for looking up the top label in any other MPLS packet it receives.  There is no special "BIER context" that can be derived before looking up the top label, so it cannot be in a context-specific label space.

In the case of an "upstream-assigned label with a precursor context-label and an ethertype of 0x8847", the context-label is treated as "downstream-assigned", in that it is looked up in the ordinary MPLS table.  The upstream-assigned label following it would then be looked up in the MPLS label table that is identified by
context label.

If the BIER-MPLS labels were assigned and distributed by a controller, the routers would still need to do the lookups in the ordinary MPLS label table (not a context-specific table), and hence the labels would still function in the dataplane as downstream-assigned labels.

With ten years of hindsight, one can see that RFC 5331 should have made a clearer distinction between (a) who binds the label and propagates the binding, and (b) which MPLS table is used for the look up.