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

From: Xiejingrong <[email-masked]>
Date: Sat, 30 Sep 2017 09:17:59 +0000

Another minor point:

chap 3 has a title "Imposing and Processing the BIER Encapsulation".  Should this chap focus on specifying the data-plane aspect ?

The 1/2/3/4/5/6 and a/b/c/d is not very continuous, and they seems to be control-plane and data-plane respectively.

There are paragraphs about BFIR (with a/b/c/d) processing, intermediate BFR processing, but BFER/BUD processing is only implied in the last paragraph.

Again, chap 3 describe "An MPLS label stack is then prepended to the packet. This label stack [RFC3032] will contain one label, the aforementioned BIER-MPLS label."

I wonder, If the whole label stack only allow One label,  will the ability/possibility to run over a MPLS transport-network lost ?

I am confused, which level is BIER belong to in OSI 7-levels mode, compared to the traditional layer 2.5 MPLS 'tunnel' ?

发件人: Xiejingrong
发送时间: 2017年9月30日 10:41
收件人: 'Eric C Rosen' <[email-masked]>; Tony Przygienda <[email-masked]>
抄送: Alia Atlas <[email-masked]>; [email-masked]; [email-masked]
主题: 答复: [Bier] AD review of draft-ietf-bier-mpls-encapsulation-08

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]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>
抄送: Alia Atlas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [Bier] AD review of draft-ietf-bier-mpls-encapsulation-08

On 9/29/2017 8:29 AM, Xiejingrong wrote:

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 ?

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

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

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.

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 30 Sep 2017 07:27:00 -0700

Mrses Xuxiaohu & Xiejingrong, your comments are late, broad and generic in
nature. Generally, I don't think they point out any technical defects that
merit attention but extend alternative ideas, seek clarification and
alternative text to be written.

* For alternative ideas we encourage procurement of new drafts
* For clarification people on this list will chime in if necessary whereas
MPLS as idea/papers/minutes/technology/deployed products exist for many,
many years and literature is widely available for consultation
* For suggestions along the lines of alternative text of the draft I
observe that the WG LC has been very long and very extensive and is closed
since long time. The document @ this point in time is in the hands of
Directorate & IESG reviewers. Obviously, nits and serious technical defects
are still of interest but I don't see neither in your mails

thanks

-- tony

On Sat, Sep 30, 2017 at 2:17 AM, Xiejingrong <[email-masked]> wrote:

> Another minor point:
>
> chap 3 has a title "Imposing and Processing the BIER Encapsulation".
> Should this chap focus on specifying the data-plane aspect ?
>
> The 1/2/3/4/5/6 and a/b/c/d is not very continuous, and they seems to be
> control-plane and data-plane respectively.
>
> There are paragraphs about BFIR (with a/b/c/d) processing, intermediate
> BFR processing, but BFER/BUD processing is only implied in the last
> paragraph.
>
>
>
> Again, chap 3 describe "An MPLS label stack is then prepended to the
> packet. This label stack [RFC3032] will contain one label, the
> aforementioned BIER-MPLS label."
>
> I wonder, If the whole label stack only allow One label,  will the
> ability/possibility to run over a MPLS transport-network lost ?
>
> I am confused, which level is BIER belong to in OSI 7-levels mode,
> compared to the traditional layer 2.5 MPLS 'tunnel' ?
>
>
>
>
>
> *发件人:* Xiejingrong
> *发送时间:* 2017年9月30日 10:41
> *收件人:* 'Eric C Rosen' <[email-masked]>; Tony Przygienda <
> [email-masked]>
> *抄送:* Alia Atlas <[email-masked]>; [email-masked]; draft-ietf-bier-mpls-
> [email-masked]
> *主题:* 答复: [Bier] AD review of draft-ietf-bier-mpls-encapsulation-08
>
>
>
> Hi, Tony and Rosen,
>
> 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.
>
> *发件人:* Eric C Rosen [mailto:[email-masked] <[email-masked]>]
> *发送时间:* 2017年9月29日 22:20
> *收件人:* Xiejingrong <[email-masked]>; Tony Przygienda <
> [email-masked]>
> *抄送:* Alia Atlas <[email-masked]>; [email-masked]; draft-ietf-bier-mpls-
> [email-masked]
> *主题:* Re: [Bier] AD review of draft-ietf-bier-mpls-encapsulation-08
>
>
>
> 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.
>
> 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.
>
> 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.
>
>
>