Subject: [Bier] BIER encapsulation

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 20 Oct 2014 08:39:48 +0200

Hi Xiaohu,

+ [email-masked]

>> I've already answered that on the bier list. Moreover, how much of MPLS
>> remains with BIER? Its really an encapsulation indirection that allows us to do
>> really useful stuff. If we decide to remove that indirection, we just have to
>> replace some of the fields we get for free in MPLS in a new encoding. This is no
> 
> There is no free lunch. When using the MPLS-BIER label as an indirection layer, you would have to introduce an additional mechanism for MPLS-BIER label distribution which is otherwise not required in the case where a transport-

True, you have to advertise labels through the IGP. But you have to advertise your BFR-id, supported BitString Length and potential MT-ID through the network as well, attaching a Label value to that update is not a big deal.

> independent BIER header is used. Furthermore, when this technology is applied to the data center networks, the usage of MPLS labels is not much popular.

If you say there is no need to distribute labels when going with an independent BIER header, that would mean you have to allocate some reserved label for BIER. If we do that, we through away the baby with the bathwater. We are using the BIER MPLS label as an indirection for {MT-ID, Set-ID, BitString Length} (and potentially some other value that Tony is working on). Having this indirection is very useful because it saves us many lookups and makes the forwarding plane independent of any of these values, which also allows us to modify and add new values without the need to change the data-plane. This is an advantage that MPLS bring to the table and we would be nuts if we through that out.

If datacenter like to use BIER (and don’t want MPLS), we can just define an encapsulation for datacenter. There is no reason to make the encapsulation generic for that reason. The BIER forwarding layer as how its implemented in the router should be generic such that it can be re-used, it does not mean the encapsulation that the BIER BitString comes in has to be generic. If you want a beer, do you care if it comes in a can or a bottle? :-)

Thx,

Ice.

> 
> Best regards,
> Xiaohu
> 
>> rocket science. The true value of a shared BIER forwarding layer comes in the
>> mechanism how you process the BitString, whether that comes via MPLS,
>> ethernet, or something else, does not matter.
>> 
>> Thx,
>> 
>> Ice.
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Oct 2014 09:49:14 +0200

Hey Ice,

> True, you have to advertise labels through the IGP.

I wonder why did you choose to do that as opposed to define a "well
known" label value which would punt the packets to BIER switching path
?

Is this for MVPN reasons so upon arrival packets will end up already
in different contexts ? If so do you plan to carry now in IGP as much
BIER MPLS labels as number of PEs * number of BIER enabled VPNs on
each PE ?

> But you have to advertise your BFR-id, supported BitString Length and
> potential MT-ID through the network as well, attaching a Label value to
> that update is not a big deal.

Well that is an option.

Alternative would be to leave the IGP (or in general routing) alone
and only say via I2RS distribute BIER info as an pure overlay to both
- edges and participating P nodes.

> If you say there is no need to distribute labels when going with an independent BIER header, that would mean you have to allocate some reserved label for BIER. If we do that, we through away the ba…

Why I would love to let's not argue about MPLS or no MPLS this time.
You need some demux field. Such demux can be GRE key or MPLS label or
LISP Instance ID .. that does not matter that much. All of your
ingredients as well as new ones can be converted into such value and
used in a *single* lookup.

You claim let's use MPLS as the lookup table is ready for it - that is
true and I would not much argue about that - at least for those
devices which support MPLS lookup.

How about those which do not and are not going to ? Think about l3vpn
for end systems draft (or soon RFC) to start with .... Do you really
want to limit BIER so narror to think about only few vendors core
boxes ?

What seems however much more important here is amount of state you are
going to add to plain IGP to accommodate your current or TonyP's
future ideas ... yes IGP is already polluted to some extend, but I
think we have now learned a bit more from past mistakes and at least
some folks are shifting applications to where they belong .. ie
overlay layer.

> If datacenter like to use BIER (and don’t want MPLS), we can just define an encapsulation for datacenter. There is no reason to make the encapsulation generic for that reason. The BIER forwarding l…

No. That would be no point .. sorry. There is nothing which would
prevent new header to work in WAN as well so if we ack that current
proposed header does not solve the problem it needs to be fixed
generically.

Best,
r.

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

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Oct 2014 08:15:19 +0000

Hi Ice,

> -----Original Message-----
> From: IJsbrand Wijnands [mailto:[email-masked]]
> Sent: Monday, October 20, 2014 2:40 PM
> To: Xuxiaohu
> Cc: [email-masked]
> Subject: BIER encapsulation
> 
> Hi Xiaohu,
> 
> + [email-masked]
> 
> >> I've already answered that on the bier list. Moreover, how much of
> >> MPLS remains with BIER? Its really an encapsulation indirection that
> >> allows us to do really useful stuff. If we decide to remove that
> >> indirection, we just have to replace some of the fields we get for
> >> free in MPLS in a new encoding. This is no
> >
> > There is no free lunch. When using the MPLS-BIER label as an
> > indirection layer, you would have to introduce an additional mechanism
> > for MPLS-BIER label distribution which is otherwise not required in
> > the case where a transport-
> 
> True, you have to advertise labels through the IGP. But you have to advertise
> your BFR-id, supported BitString Length and potential MT-ID through the
> network as well, attaching a Label value to that update is not a big deal.

Although attaching a label to that update is not a big deal, it implies that intermediate routers would have to support the MPLS data plane which is otherwise not needed at all in the transport-independent BIER encapsulation scheme (https://tools.ietf.org/html/draft-xu-bier-encapsulation-01) and the mappings of BFR-ID and BFR-prefix which are otherwise only meaningful for adjacent peers would have be unnecessarily flooded across the whole IGP area or ever domain. BTW, you actually don't have to advertise the BFR-ID (which is only needed for ingress and egress routers) and MT-ID (https://tools.ietf.org/html/draft-xu-ospf-bier-cap-00) .

> > independent BIER header is used. Furthermore, when this technology is
> applied to the data center networks, the usage of MPLS labels is not much
> popular.
> 
> If you say there is no need to distribute labels when going with an independent
> BIER header, that would mean you have to allocate some reserved label for BIER.

It depends on whether the BIER-encapsulated packets need to traverse LSPs in most cases. If no, that reserved label for indicating the MPLS payload is a BIER-encapsulated packet is not needed at all. That's the reason that I prefer to a transport-independent BIER encapsulation header rather than an MPLS-coupled BIER encapsulation header. 

> If we do that, we through away the baby with the bathwater. We are using the
> BIER MPLS label as an indirection for {MT-ID, Set-ID, BitString Length} (and
> potentially some other value that Tony is working on). Having this indirection is
> very useful because it saves us many lookups and makes the forwarding plane
> independent of any of these values, which also allows us to modify and add new
> values without the need to change the data-plane. This is an advantage that
> MPLS bring to the table and we would be nuts if we through that out.

IMHO, no change to the DATA FORMAT doesn't mean no change to the DATA PLANE when modifying and adding new values/fields.

> If datacenter like to use BIER (and don't want MPLS), we can just define an
> encapsulation for datacenter. There is no reason to make the encapsulation
> generic for that reason. The BIER forwarding layer as how its implemented in the
> router should be generic such that it can be re-used, it does not mean the
> encapsulation that the BIER BitString comes in has to be generic. If you want a
> beer, do you care if it comes in a can or a bottle? :-)

If a single forwarding plane (i.e., the BIER forwarding plane) is good enough, why introduce two (i.e., MPLS forwarding plane and BIER forwarding plane)?

Best regards,
Xiaohu

> Thx,
> 
> Ice.
> 
> >
> > Best regards,
> > Xiaohu
> >
> >> rocket science. The true value of a shared BIER forwarding layer
> >> comes in the mechanism how you process the BitString, whether that
> >> comes via MPLS, ethernet, or something else, does not matter.
> >>
> >> Thx,
> >>
> >> Ice.
> >

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 20 Oct 2014 10:15:48 +0200

Hi Robert,

> known" label value which would punt the packets to BIER switching path

I answered that in the last email:

...
Having this indirection is very useful because it saves us many lookups and makes the forwarding plane independent of any of these values, which also allows us to modify and add new values without the need to change the data-plane. This is an advantage that MPLS bring to the table and we would be nuts if we through that out.
...

> BIER MPLS labels as number of PEs * number of BIER enabled VPNs on

No.

> - edges and participating P nodes.

The BFR-id needs to be known on all IGP routers in the network, this is not an overlay function.

> used in a *single* lookup.

Yes, its just that your ‘key’ becomes very long. We can of course re-invent the same functionality and call it something different...

> want to limit BIER so narror to think about only few vendors core

I see no problem in defining a new encapsulation for BIER in non-MPLS networks. I don’t see what the value is in a generic encapsulation where we throw away benefits we get through MPLS. Yes, we can re-invent those benefits back into it, but what have we gained. Just more complexity. 

> some folks are shifting applications to where they belong .. ie

I’m all for overlay in this context.

Thx,

Ice.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Oct 2014 08:22:02 +0000

Just fix an error.

> From: Xuxiaohu
> Sent: Monday, October 20, 2014 4:15 PM
> To: 'IJsbrand Wijnands'
> Cc: [email-masked]
> Subject: RE: BIER encapsulation
> 
> Hi Ice,
> 
> > >> MPLS remains with BIER? Its really an encapsulation indirection
> > >> that allows us to do really useful stuff. If we decide to remove
> > >> that indirection, we just have to replace some of the fields we get
> > >> for free in MPLS in a new encoding. This is no
> > >
> > > indirection layer, you would have to introduce an additional
> > > mechanism for MPLS-BIER label distribution which is otherwise not
> > > required in the case where a transport-
> >
> > True, you have to advertise labels through the IGP. But you have to
> > advertise your BFR-id, supported BitString Length and potential MT-ID
> > through the network as well, attaching a Label value to that update is not a big
> deal.
> 
> Although attaching a label to that update is not a big deal, it implies that
> intermediate routers would have to support the MPLS data plane which is
> otherwise not needed at all in the transport-independent BIER encapsulation
> scheme (https://tools.ietf.org/html/draft-xu-bier-encapsulation-01) and the
> mappings of BFR-ID and BFR-prefix which are otherwise only meaningful for

s/the mappings of BFR-ID and BFR-prefix/the BIER-MPLS labels

Best regards,
Xiaohu

> adjacent peers would have be unnecessarily flooded across the whole IGP area
> or ever domain. BTW, you actually don't have to advertise the BFR-ID (which is
> only needed for ingress and egress routers) and MT-ID
> (https://tools.ietf.org/html/draft-xu-ospf-bier-cap-00) .
> 
> > applied to the data center networks, the usage of MPLS labels is not
> > much popular.
> >
> > If you say there is no need to distribute labels when going with an
> > independent BIER header, that would mean you have to allocate some
> reserved label for BIER.
> 
> It depends on whether the BIER-encapsulated packets need to traverse LSPs in
> most cases. If no, that reserved label for indicating the MPLS payload is a
> BIER-encapsulated packet is not needed at all. That's the reason that I prefer to a
> transport-independent BIER encapsulation header rather than an MPLS-coupled
> BIER encapsulation header.
> 
> > If we do that, we through away the baby with the bathwater. We are
> > using the BIER MPLS label as an indirection for {MT-ID, Set-ID,
> > BitString Length} (and potentially some other value that Tony is
> > working on). Having this indirection is very useful because it saves
> > us many lookups and makes the forwarding plane independent of any of
> > these values, which also allows us to modify and add new values
> > without the need to change the data-plane. This is an advantage that MPLS
> bring to the table and we would be nuts if we through that out.
> 
> IMHO, no change to the DATA FORMAT doesn't mean no change to the DATA
> PLANE when modifying and adding new values/fields.
> 
> > If datacenter like to use BIER (and don't want MPLS), we can just
> > define an encapsulation for datacenter. There is no reason to make the
> > encapsulation generic for that reason. The BIER forwarding layer as
> > how its implemented in the router should be generic such that it can
> > be re-used, it does not mean the encapsulation that the BIER BitString
> > comes in has to be generic. If you want a beer, do you care if it
> > comes in a can or a bottle? :-)
> 
> If a single forwarding plane (i.e., the BIER forwarding plane) is good enough,
> why introduce two (i.e., MPLS forwarding plane and BIER forwarding plane)?
> 
> Best regards,
> Xiaohu
> 
> > Thx,
> >
> > Ice.
> >
> > >
> > > Best regards,
> > > Xiaohu
> > >

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Oct 2014 10:35:36 +0200

Hi,

Why would such key become very long ? If you can fit the demux into 20 bits
the key also wouldn't need to be  much longer ... no ?

Best,
R.
On Oct 20, 2014 10:15 AM, "IJsbrand Wijnands" <[email-masked]> wrote:

> Having this indirection is very useful because it saves us many lookups
> and makes the forwarding plane independent of any of these values, which
> also allows us to modify and add new values without the need to change the
> data-plane. This is an advantage that MPLS bring to the table and we would
> be nuts if we through that out.
> ...
>
> >
> independent BIER header, that would mean you have to allocate some reserved
> label for BIER. If we do that, we through away the baby with the bathwater.
> We are using the BIER MPLS label as an indirection for {MT-ID, Set-ID,
> BitString Length} (and potentially some other value that Tony is working
> on). Having this indirection is very useful because it saves us many
> lookups and makes the forwarding plane independent of any of these values,
> which also allows us to modify and add new values without the need to
> change the data-plane. This is an advantage that MPLS bring to the table
> and we would be nuts if we through that out.
> >
> >
> Yes, its just that your ‘key’ becomes very long. We can of course
> re-invent the same functionality and call it something different...
>
> I see no problem in defining a new encapsulation for BIER in non-MPLS
> networks. I don’t see what the value is in a generic encapsulation where we
> throw away benefits we get through MPLS. Yes, we can re-invent those
> benefits back into it, but what have we gained. Just more complexity.
>
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 20 Oct 2014 10:45:38 +0200

Robert,

> Why would such key become very long ? If you can fit the demux into 20 bits the key also wouldn't need to be  much longer ... no ?

Great, lets architect a solution that looks, feels and smells like MPLS, and call it something different :-)

Thx,

Ice.

---

From: "S, Somasundaram (Somasundaram)" <[email-masked]>
Date: Mon, 20 Oct 2014 08:45:33 +0000

Hi Ice,
	It's all understood that "MT-ID, set id and Bit String" needs to be represented in the data plane as a single variable.. And you had chosen to use MPLS label...
	But, except for the hardware performance (which is not a problem at all with today's ASICs or FPGAs), what are the benefits this approach of maintaining different  encapsulation for different scenarios brings to the table?

	Why would you recommend adopting a different encapsulation for a different operating environment?
 
	I believe this has been discussed earlier in the list but we haven't gone beyond discussing about HW performance yet... 

Regards
Somasundaram

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands
Sent: Monday, October 20, 2014 12:10 PM
To: Xuxiaohu
Cc: [email-masked]
Subject: [Bier] BIER encapsulation

Hi Xiaohu,

+ [email-masked]

If datacenter like to use BIER (and don't want MPLS), we can just define an encapsulation for datacenter. There is no reason to make the encapsulation generic for that reason. The BIER forwarding layer as how its implemented in the router should be generic such that it can be re-used, it does not mean the encapsulation that the BIER BitString comes in has to be generic. If you want a beer, do you care if it comes in a can or a bottle? :-)

Thx,

Ice.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Oct 2014 08:52:53 +0000

Hi Ice,

Please see the attached about the comparison between the BIER header and the IPv6 header. IMHO, the BIER layer is almost a totally-new network layer and therefore the corresponding header format is much similar with the IPv6 header.

Best regards,
Xiaohu

> Sent: Monday, October 20, 2014 4:46 PM
> To: Robert Raszuk
> Cc: [email-masked]; Xuxiaohu
> Subject: Re: [Bier] BIER encapsulation
> 
> Robert,
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Oct 2014 11:09:02 +0200

Hey Ice,

Glad we are progressing :)

I have even better idea ... let's ignore reality of GRE and VXLAN being
already supported in millions of linux hosts acting as PEs and start
campagne of new MPLS stack and IGP obviously to all of them only because
few equipment vendors have boxes with mpls deployed here and there ...

Cheers,
R.
On Oct 20, 2014 10:45 AM, "IJsbrand Wijnands" <[email-masked]> wrote:

> Robert,
>
> > Why would such key become very long ? If you can fit the demux into 20
> bits the key also wouldn't need to be  much longer ... no ?
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 20 Oct 2014 14:24:53 +0200

Hi Somasundaram,

> 	But, except for the hardware performance (which is not a problem at all with today's ASICs or FPGAs), what

That’s assuming there are ASIC’s to do this, and, that is still no good reason to waste the resources while its not necessary.

>  are the benefits this approach of maintaining different  encapsulation for different scenarios brings to the table?

Each encapsulation, MPLS, Ethernet, IPv6 Extension header, GRE, Vxlan, (and there are many more), have their own characteristics. I don’t think this is the moment to settle on a generic encapsulation throwing away advantages that each encapsulation has.

> Why would you recommend adopting a different encapsulation for a different operating environment?

Because you’ll settle on the lowest common denominator. If that happens to be the same, then fine.

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 20 Oct 2014 14:35:17 +0200

Hi Xiaohu,

I don’t see how a IPv6 header is similar to a BIER header, but I agree the BIER header is a new layer. I would say BIER is more like MPLS. Meaning, a sub-header between L2 and L3 that determines the ‘intermediate’ end destination(s).

Thx,

Ice.

On 20 Oct 2014, at 10:52, Xuxiaohu <[email-masked]> wrote:

> <BIER header vs IPv6 header.JPG>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 20 Oct 2014 14:49:48 +0200

Robert,

> I have even better idea ... let's ignore reality of GRE and VXLAN being already supported in millions of linux hosts acting as PEs and start campagne of new MPLS stack and IGP obviously to all of them only because few equipment vendors have boxes with mpls deployed here and there …

And I’ll be the first one to be very happy to see the BIER technology spread into multiple area’s. And to me it does not have to be MPLS at all if that is not the right way to do it in those area’s. My point is, if you want to use MPLS, don’t throw out MPLS advantages by going to a generic encapsulation, while its not even sure if/how its going to apply to other area’s. 

Lets look at real use-cases in other area’s and see how BIER applies and then determine how to encapsulate it, instead of assuming its applicability. Can you help in doing that? 

Thx,

Ice.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 09:40:17 -0400

However one does the BIER encapsulation, one still has to extract a 
lookup key from the header, and then use that key to find the BIFT 
context in which the packet's BitString is to be processed.

With the MPLS encapsulation, the lookup key is the MPLS label that 
already appears in the header.  In the "generic" encapsulation, the 
lookup key has to be constructed from fields in the BIER header.  I see 
a couple of advantages in using the MPLS encapsulation:

1. Looking up the MPLS label immediately gives you the BIFT context in 
which the BitString is to be processed.  So you save the steps of 
concatenating various fields from the BIER header to produce the lookup 
key that then gives you the context.

2. Since the BIFT context is determined by the label, not by the BIER 
header, the assignment of a given packet to a given context doesn't 
depend upon the fields in the data plane header at all. Suppose we 
decide someday that we want to use a "special" BIFT for traffic from 
certain "special" subscribers.  We could do this just by making the 
appropriate modifications in the control plane; we wouldn't have to 
change the BIER header to carry a "subscriber id", and we wouldn't have 
to modify the forwarding procedure to change the way the lookup key is 
constructed.  This flexibility is very similar to the flexibility that 
MPLS provides to unicast forwarding -- an ingress node can assign a 
packet to a "forwarding equivalence class", where that assignment is 
based on information that does not appear explicitly in the data plane 
header.

If one thinks that most BIER usage will be on MPLS networks, it seems 
logical to take advantage of these properties of MPLS.

I see the point that BIER may be valuable in DC networks, where one 
doesn't want to introduce multicast tree-building protocols, but one 
also doesn't want the inefficiency of IR.  However, if one is going to 
introduce a BIER forwarding plane into those environments, one could 
also introduce an MPLS forwarding plane.  After all, BIER is already 
incompatible with existing DC routers.

For those who object to introducing MPLS in the DC environment, we can 
just say that the MPLS label is part of the BIER header, we can rename 
it to be the "non-MPLS 20-bit BIER lookup key that just happens to 
resemble the MPLS label stack".   As has been pointed out, there is no 
MPLS-specific signaling needed to distributed the label values, as this 
is done via the same IGP extensions used to distributed the 
BIER-specific control info.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Oct 2014 15:40:33 +0200

Hi Ice,

Your explanation would perhaps hold if you assume completely isolated
environments. However these days hosts talk to routers and vice versa.

Hence if you do two different data plane encapsulations you are stuck
into building expensive gateways which will have to convert paradigms.

Knowing apriori (based on our past mistakes) that this is coming why
would you not avoid it in the first place ?

Thx,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Oct 2014 15:46:03 +0200

Hi Eric,

> As has been pointed out, there is no MPLS-specific signaling
> needed to distributed the label values, as this is done via the
> same IGP extensions used to distributed the BIER-specific
> control info.

How about data centers which do not run IGP ? Should they forget
about BIER ?

Also how many BIER MPLS labels do you envision will be advertised by
each L3VPN PE into IGP ?

Thx,
R.

On Mon, Oct 20, 2014 at 3:40 PM, Eric Rosen <[email-masked]> wrote:
> However one does the BIER encapsulation, one still has to extract a lookup
> key from the header, and then use that key to find the BIFT context in which
> the packet's BitString is to be processed.
>
> With the MPLS encapsulation, the lookup key is the MPLS label that already
> appears in the header.  In the "generic" encapsulation, the lookup key has
> to be constructed from fields in the BIER header.  I see a couple of
> advantages in using the MPLS encapsulation:
>
> 1. Looking up the MPLS label immediately gives you the BIFT context in which
> the BitString is to be processed.  So you save the steps of concatenating
> various fields from the BIER header to produce the lookup key that then
> gives you the context.
>
> header, the assignment of a given packet to a given context doesn't depend
> upon the fields in the data plane header at all. Suppose we decide someday
> that we want to use a "special" BIFT for traffic from certain "special"
> subscribers.  We could do this just by making the appropriate modifications
> in the control plane; we wouldn't have to change the BIER header to carry a
> "subscriber id", and we wouldn't have to modify the forwarding procedure to
> change the way the lookup key is constructed.  This flexibility is very
> similar to the flexibility that MPLS provides to unicast forwarding -- an
> ingress node can assign a packet to a "forwarding equivalence class", where
> that assignment is based on information that does not appear explicitly in
> the data plane header.
>
> I see the point that BIER may be valuable in DC networks, where one doesn't
> want to introduce multicast tree-building protocols, but one also doesn't
> want the inefficiency of IR.  However, if one is going to introduce a BIER
> forwarding plane into those environments, one could also introduce an MPLS
> forwarding plane.  After all, BIER is already incompatible with existing DC
> routers.
>
> For those who object to introducing MPLS in the DC environment, we can just
> say that the MPLS label is part of the BIER header, we can rename it to be
> the "non-MPLS 20-bit BIER lookup key that just happens to resemble the MPLS
> label stack".   As has been pointed out, there is no MPLS-specific signaling
> needed to distributed the label values, as this is done via the same IGP
> extensions used to distributed the BIER-specific control info.
>
>
>
>
>
>
>

---

From: "S, Somasundaram (Somasundaram)" <[email-masked]>
Date: Mon, 20 Oct 2014 15:15:30 +0000

Hi Eric,
	Thanks for your views.... But, MPLS header is actually followed by BIER header which means that every BIR neighbor (or every router in the BIER domain) will have to process the BIER header.. The forwarding logic to perform based on the BIER header is defined in "draft-wijnands-bier-architecture-00"... The MPLS label only identifies the BIR here. So despite being MPLS encapsulated, "Bit string, set id and MT-ID" are used for replication.
	
Regards
Somasundaram

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Eric Rosen
Sent: Monday, October 20, 2014 7:10 PM
To: IJsbrand Wijnands; Robert Raszuk
Cc: Xuxiaohu; [email-masked]; [email-masked]
Subject: Re: [Bier] BIER encapsulation

However one does the BIER encapsulation, one still has to extract a lookup key from the header, and then use that key to find the BIFT context in which the packet's BitString is to be processed.

With the MPLS encapsulation, the lookup key is the MPLS label that already appears in the header.  In the "generic" encapsulation, the lookup key has to be constructed from fields in the BIER header.  I see a couple of advantages in using the MPLS encapsulation:

1. Looking up the MPLS label immediately gives you the BIFT context in which the BitString is to be processed.  So you save the steps of concatenating various fields from the BIER header to produce the lookup key that then gives you the context.

2. Since the BIFT context is determined by the label, not by the BIER header, the assignment of a given packet to a given context doesn't depend upon the fields in the data plane header at all. Suppose we decide someday that we want to use a "special" BIFT for traffic from certain "special" subscribers.  We could do this just by making the appropriate modifications in the control plane; we wouldn't have to change the BIER header to carry a "subscriber id", and we wouldn't have to modify the forwarding procedure to change the way the lookup key is constructed.  This flexibility is very similar to the flexibility that MPLS provides to unicast forwarding -- an ingress node can assign a packet to a "forwarding equivalence class", where that assignment is based on information that does not appear explicitly in the data plane header.

If one thinks that most BIER usage will be on MPLS networks, it seems logical to take advantage of these properties of MPLS.

I see the point that BIER may be valuable in DC networks, where one doesn't want to introduce multicast tree-building protocols, but one also doesn't want the inefficiency of IR.  However, if one is going to introduce a BIER forwarding plane into those environments, one could also introduce an MPLS forwarding plane.  After all, BIER is already incompatible with existing DC routers.

For those who object to introducing MPLS in the DC environment, we can just say that the MPLS label is part of the BIER header, we can rename it to be the "non-MPLS 20-bit BIER lookup key that just happens to 
resemble the MPLS label stack".   As has been pointed out, there is no 
MPLS-specific signaling needed to distributed the label values, as this is done via the same IGP extensions used to distributed the BIER-specific control info.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 11:16:48 -0400

Robert> How about data centers which do not run IGP ? Should they forget about BIER ?

Whatever technique is used to set up the BIER control information can be used to set up the labels as well.

Robert> how many BIER MPLS labels do you envision will be advertised by each L3VPN PE

I'm not sure exactly what you're asking.  The labels in question are not specific to the application.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Oct 2014 17:20:46 +0200

> used to set up the labels as well.

Great. Shouldn't architecture document describe those options rather then
locking on one specific one already ?

> specific to the application.

I was under impression that for MVPN MPLS BIER label will get you to
different per VPN BIER context .. if not that I really don't see the
reason to have this label to be dynamically distributed.

New ethertype may be a much better and much more general option.

r.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 11:22:32 -0400

On 10/20/2014 11:15 AM, S, Somasundaram (Somasundaram) wrote:

> The MPLS label only identifies the BIR here.

I'm not sure what you mean by "BIR".  Did you mean "BFR"?  If so, the statement is not correct.

> So despite being MPLS encapsulated, "Bit string, set id and MT-ID" are used for replication.

Not following.  In the MPLS encaps, set id and mt-id are not in the BIER header.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 11:25:46 -0400

> I was under impression that for MVPN MPLS BIER label will get you to different per VPN BIER context

For an MVPN packet, the VRF context would be determined by the label 
stack that is part of the payload (i.e., that appears after the BIER 
header), in conjunction with the BFIR-id that is in the BIER header.  
The label we've been discussing in this thread is the one that appears 
before the BIER header.

---

From: "S, Somasundaram (Somasundaram)" <[email-masked]>
Date: Mon, 20 Oct 2014 15:37:54 +0000

Yes... I was referring to BFR .. Can you clarify on why is the statement not correct?

>>>Not following.  In the MPLS encaps, set id and mt-id are not in the BIER header.

I apologize.. just got confused with the other proposal on encapsulation..

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Oct 2014 15:37:27 +0000

If I understand it correctly, the purpose of the BIER-MPLS label include: 1) a lookup key for the SI 
and MT-ID values; 2) a protocol identifier for the BIER-encapsulated packet.

Now assume SI and MT-ID values have been carried in the BIER header, the only remaining purpose of the BIER-MPLS label is the protocol identifier. As Robert had pointed out, the Ethertype field is a more generic way for that remaining purpose.

Best regards,
Xiaohu
________________________________________
发件人: Eric Rosen [[email-masked]]
发送时间: 2014年10月20日 23:25
收件人: Robert Raszuk
抄送: [email-masked]; IJsbrand Wijnands; Xuxiaohu; [email-masked]
主题: Re: [Bier] BIER encapsulation

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 20 Oct 2014 15:43:46 +0000

I want to add that, even if the topology and SI are encoded in the BIER header itself, in case of MPLS based FRR, we still need another label to indicate that a BIER header follows.

For that you either use a special label, or just use a regular label that also gives you the topology and SI all the time, for the benefits that Eric explained below.

Jeffrey

> Sent: Monday, October 20, 2014 9:40 AM
> Cc: Xuxiaohu; [email-masked]; Eric Rosen

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Oct 2014 17:57:49 +0200

And what is the advantage of MPLS FRR now as compared with LFA (either
native or its topology enhance version) ?

The choice is simple ... you continue into closed and limited data plane
paradigm or you keep it open. Choice is yours.

Best,
R.
On Oct 20, 2014 5:43 PM, "Jeffrey (Zhaohui) Zhang" <[email-masked]>
wrote:

> I want to add that, even if the topology and SI are encoded in the BIER
> header itself, in case of MPLS based FRR, we still need another label to
> indicate that a BIER header follows.
>
> For that you either use a special label, or just use a regular label that
> also gives you the topology and SI all the time, for the benefits that Eric
> explained below.
>
> Jeffrey
>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Oct 2014 16:00:30 +0000

In the MPLS transport network, I agree with you that we still need a way to indicate the BIER header following the MPLS label stack even through the MT-ID and SI values have been encoded in the BIER header. Now it seems that the only work we need to do is just to find a way to indicate the MPLS payload type. In fact, there are many ways.

There is no free lunch. To obtain the benefits, you have to afford the corresponding costs (e.g., unnessary flooding of the label mappings across the whole IGP area or domain, the troubleshooting complexity introduced by that indirection, the MPLS forwarding plane which is otherwise unnecessary)

Best regards,
Xiaohu

________________________________________
发件人: Jeffrey (Zhaohui) Zhang [[email-masked]]
发送时间: 2014年10月20日 23:43
收件人: Eric Rosen; IJsbrand Wijnands; Robert Raszuk
抄送: Xuxiaohu; [email-masked]; Eric Rosen
主题: RE: [Bier] BIER encapsulation

Jeffrey

---

From: Alia Atlas <[email-masked]>
Date: Mon, 20 Oct 2014 12:21:41 -0400

Robert,

> native or its topology enhance version) ?
Regardless of how the alternate is computed, there can still be an MPLS
label indicating the merge-point; then the existence of a BIER header would
have to be indicated next on the stack.

> paradigm or you keep it open. Choice is yours.
I think this comes down to common use-cases and deployments.  Understanding
the technology and problem scope is a primary focus of the upcoming BoF.

One clear use-case that maps to a highly deployed case is MPLS for MVPN.
Certainly, that seems to be a good motivator.

I can certainly see BIER being useful in the DC case - as I pointed out to
the NVO3 chairs.  However, I don't see a need to create another full
overlay encapsulation (complete with TTL, QoS, etc.).  One question with
BIER is whether it is viewed like a pseudo-wire header or a new
encapsulation or such?  I do think there could be a common base and then
either an optional first word or two, depending.  Taking a look at what
type of extension/encapsulation would make sense for vxlan sounds
interesting - but there are also some change control issues for the IETF
around vxlan.

Regards,
Alia

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 20 Oct 2014 16:50:27 +0000

Hi Somasundaram,

The Bit string to be used for forwarding will be pulled from the BiER
header. But the SI and/or MT-ID doesn¹t require a look in BiER header as
it can be inferred from the label itself. As mentioned in BiER encap and
OSPF extension draft, in MPLS network, a unique label will be assigned for
each Bitstream length (or simply for each SI) and MT-ID. So we save the
context lookup in BiER header (by looking into different fields). Instead
a label lookup will help identify the context into which the actual bit
string lookup should be performed.

Thanks,
Nagendra

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 21 Oct 2014 05:51:27 +0000

Hi Ice,

From the functionality perspective, IMHO, the BIER header is much similar with the IPv6 header which is used as an underlay encapsulation header for overlay multicast/broadcast/unkown-unicast packets. In the former case, all the receivers of a given BIER-encapsulated packet are explicitly indicated by the combination of the SI and BitString fields. In the latter case, all the receivers of the IPv6-encapsulated packet are indirectly indicated by the multicast destination address.   In the former case, the sender of the BIER-encapsulated packet is indicated by the BFIR-ID, in the latter case, the sender of the IPv6-encapsulated packet is indicated by the source address field.  To support MT-routing, the BIER-header should contain an MT-ID field (IPv6 uses the DS/TC field, as a result, there is no way to support both Diff-serv and MT-routing simultaneously, that pity is fixed now by introducing a dedicated MT-ID field!). To support load-balancing, the BIER-header should contain an entropy field (similar to the IPv6 FL). To support Diff-serv, the BIER-header should contain a DS field (similar to the IPv6 DS/TC field). To avoid transient loop, the BIER header should contain a TTL field. Of course, the Version and Protocol fields are mandatory. As the IPv6-encapsulated packet could be transported over any kind of link-layers including but not limited to Ethernet and PPP, the BIER-encapsulated could be transport over those link-layers as well. Meanwhile, as the IPv6-encapsulated packet could traverse any kind of tunnels such as MPLS LSP tunnels and GRE tunnels, the BIER-encapsulated packet could traverse those tunnels as well. 

Best regards,
Xiaohu

________________________________________
发件人: BIER [[email-masked]] 代表 IJsbrand Wijnands [[email-masked]]
发送时间: 2014年10月20日 20:35
收件人: Xuxiaohu
抄送: [email-masked]; Robert Raszuk
主题: Re: [Bier] BIER encapsulation

Hi Xiaohu,

Thx,

Ice.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 21 Oct 2014 06:41:58 +0000

Let’s have a look at one possible extreme of the BIER application: only one egress PE for a given overlay BUM packet. In this case, we could either use the BIER encapsulation by setting only one bit of the BitString which is corresponding to that egress PE or use the IP encapsulation with the destination being filled with the address of that egress PE.

Or we can think about the BIER functionality from the ingress replication perspective: assume an ingress PE needs to replicate n copies for a given overlay BUM packet with each destined for a particular egress PE. Since  n copies (n<m) need to be forwarded to a given next-hop,  the ingress PE decides to “aggregates” that n copies into one copy by listing egress PEs for those n copies within one copy.

From the above reasoning, we can find that the BIER is exactly a totally-new network layer in which one or more destination addresses could be indicated (by the BitString).

Best regards,
Xiaohu

From: Alia Atlas [mailto:[email-masked]]
Sent: Tuesday, October 21, 2014 12:22 AM
To: Robert Raszuk
Cc: Jeffrey (Zhaohui) Zhang; Xuxiaohu; [email-masked]; IJsbrand Wijnands; Eric Rosen
Subject: Re: [Bier] BIER encapsulation

Robert,

On Mon, Oct 20, 2014 at 11:57 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

And what is the advantage of MPLS FRR now as compared with LFA (either native or its topology enhance version) ?
Regardless of how the alternate is computed, there can still be an MPLS label indicating the merge-point; then the existence of a BIER header would have to be indicated next on the stack.

The choice is simple ... you continue into closed and limited data plane paradigm or you keep it open. Choice is yours.
I think this comes down to common use-cases and deployments.  Understanding the technology and problem scope is a primary focus of the upcoming BoF.

One clear use-case that maps to a highly deployed case is MPLS for MVPN.  Certainly, that seems to be a good motivator.

I can certainly see BIER being useful in the DC case - as I pointed out to the NVO3 chairs.  However, I don't see a need to create another full overlay encapsulation (complete with TTL, QoS, etc.).  One question with BIER is whether it is viewed like a pseudo-wire header or a new encapsulation or such?  I do think there could be a common base and then either an optional first word or two, depending.  Taking a look at what type of extension/encapsulation would make sense for vxlan sounds interesting - but there are also some change control issues for the IETF around vxlan.

Regards,
Alia

Best,
R.
On Oct 20, 2014 5:43 PM, "Jeffrey (Zhaohui) Zhang" <[email-masked]<mailto:[email-masked]>> wrote:
I want to add that, even if the topology and SI are encoded in the BIER header itself, in case of MPLS based FRR, we still need another label to indicate that a BIER header follows.

Jeffrey

> From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rosen
> Cc: Xuxiaohu; [email-masked]<mailto:[email-masked]>; Eric Rosen
> [email-masked]<mailto:[email-masked]>

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

---

From: Haoweiguo <[email-masked]>
Date: Tue, 21 Oct 2014 07:31:37 +0000

Hi Alia,

I agree with your opinion about BIER application in the DC case, i also think it's not necessary to introduce another overlay encapsulation in NVO3 area.

Underlay network distribution tree can be used to carry NVO3 overlay multicast traffic, the distribution tree can be established using traditional PIM protocol or using IS-IS extension similar solution. As described in BIER problem statements, currently in underlay network also there are the challenges as follows:

1. Complexity. Independant PIM like protocol should be deployed besides unicast IGP/BGP protocol.

2. Long convergence timer. Multicast network convergence catenated with unicast network convergence.

3. Maintain per flow forwarding state.

IS-IS extension similar mechanism can be used to replace PIM to reduce complexity and convergence timer, it converges unicast and multicast protocols into a single protocol.

As for per flow forwarding state,  flow state can be aggregated using the idea similar to BIER, but using standard NVO3(VXLAN/NVGRE,etc) data format instead of full new encapsulation. We can use a underlay multicast group address instead of BitString to represent a set of underlay edge devices.

If multipe overlay multicast groups attaches to same underlay edge devices, same underlay multicast group can be used to carry the traffic of these overlay multicast groups. Each NVO3 edge device uses the corresponding underlay multicast group to perform NVO3 encapsulation when it sends multicast traffic to underlay network, underlay network devices rely on the underlay multicast group to replicate and forward multicast traffic, these devices don't need maintain per flow multicast state.

Thanks

weiguo

________________________________

发件人: BIER [[email-masked]] 代表 Alia Atlas [[email-masked]]
发送时间: 2014年10月21日 0:21
收件人: Robert Raszuk
抄送: Jeffrey (Zhaohui) Zhang; Xuxiaohu; [email-masked]; IJsbrand Wijnands; Eric Rosen
主题: Re: [Bier] BIER encapsulation

Robert,

Regards,
Alia

Best,
R.

Jeffrey

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 21 Oct 2014 09:35:17 +0200

Xiaohu,

I agree with you this is a completely new way to forward and replicate multicast packets. Does it help you to think about the ‘generic’ BIER encapsulation to be like this? The Table ID is an 20 bit value used as an indirection that represents SetID, MT-ID, BitString Length, (and any other value you want to add in the future). The data-plane is not overloaded with multiple lookups, the Table ID points to the BIFT table that needs to be used to forward the packet using the BitString.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |             Table ID                  | Exp |1|       TTL     | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0|  Ver  |I|0 0 0 0 0 0 0| Proto |  Len  |   Entropy     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                BitString  (first 32 bits)                     ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                BitString  (last 32 bits)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    BFIR-id (optional)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thx,

Ice.

On 21 Oct 2014, at 08:41, Xuxiaohu <[email-masked]> wrote:

> On Oct 20, 2014 5:43 PM, "Jeffrey (Zhaohui) Zhang" <[email-masked]> wrote:

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Oct 2014 09:39:26 +0200

Ice,

What you propose has not much value as ethertype just below such
header can easily point to BIFT table. Why to have two things
(table_id and ethertype) pointing to the same context in each packet ?

r.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 21 Oct 2014 09:41:34 +0200

Because it allows you to use more then one BIFT table. Even if you don’t use MT-ID, each SetID have its own BIFT.

---

From: "S, Somasundaram (Somasundaram)" <[email-masked]>
Date: Tue, 21 Oct 2014 07:49:07 +0000

Hi Ice,
	Are you proposing this new encapsulation?

Regards
Somasundaram

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands
Sent: Tuesday, October 21, 2014 1:05 PM
To: Xuxiaohu
Cc: Jeffrey (Zhaohui) Zhang; [email-masked]; Eric Rosen; Robert Raszuk
Subject: Re: [Bier] BIER encapsulation

Xiaohu,

I agree with you this is a completely new way to forward and replicate multicast packets. Does it help you to think about the 'generic' BIER encapsulation to be like this? The Table ID is an 20 bit value used as an indirection that represents SetID, MT-ID, BitString Length, (and any other value you want to add in the future). The data-plane is not overloaded with multiple lookups, the Table ID points to the BIFT table that needs to be used to forward the packet using the BitString.

      0                   1                   2                   3

Thx,

Ice.

On 21 Oct 2014, at 08:41, Xuxiaohu <[email-masked]> wrote:

> Let's have a look at one possible extreme of the BIER application: only one egress PE for a given overlay BUM packet. In this case, we could either use the BIER encapsulation by setting only one bit of the BitString which is corresponding to that egress PE or use the IP encapsulation with the destination being filled with the address of that egress PE.
>  
> Or we can think about the BIER functionality from the ingress replication perspective: assume an ingress PE needs to replicate n copies for a given overlay BUM packet with each destined for a particular egress PE. Since  n copies (n<m) need to be forwarded to a given next-hop,  the ingress PE decides to "aggregates" that n copies into one copy by listing egress PEs for those n copies within one copy.
>  
> > lookup key has to be constructed from fields in the BIER header.  I 
> > see a couple of advantages in using the MPLS encapsulation:
> >
> > 1. Looking up the MPLS label immediately gives you the BIFT context 
> > in which the BitString is to be processed.  So you save the steps of 
> > concatenating various fields from the BIER header to produce the 
> > lookup key that then gives you the context.
> >
> > 2. Since the BIFT context is determined by the label, not by the 
> > BIER header, the assignment of a given packet to a given context 
> > doesn't depend upon the fields in the data plane header at all. 
> > Suppose we decide someday that we want to use a "special" BIFT for 
> > traffic from certain "special" subscribers.  We could do this just 
> > by making the appropriate modifications in the control plane; we 
> > wouldn't have to change the BIER header to carry a "subscriber id", 
> > and we wouldn't have to modify the forwarding procedure to change 
> > the way the lookup key is constructed.  This flexibility is very 
> > similar to the flexibility that MPLS provides to unicast forwarding 
> > -- an ingress node can assign a packet to a "forwarding equivalence 
> > class", where that assignment is based on information that does not 
> > appear explicitly in the data plane header.
> >
> > If one thinks that most BIER usage will be on MPLS networks, it 
> > seems logical to take advantage of these properties of MPLS.
> >
> > also doesn't want the inefficiency of IR.  However, if one is going 
> > to introduce a BIER forwarding plane into those environments, one 
> > could also introduce an MPLS forwarding plane.  After all, BIER is 
> > already incompatible with existing DC routers.
> >
> > For those who object to introducing MPLS in the DC environment, we 
> > can just say that the MPLS label is part of the BIER header, we can 
> > rename it to be the "non-MPLS 20-bit BIER lookup key that just happens to
> > MPLS-specific signaling needed to distributed the label values, as 
> > this is done via the same IGP extensions used to distributed the

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Oct 2014 09:50:24 +0200

But proposed header has exactly 20 bits to use different BIFT too ... it is
just they are call differently
​: SI + MT-ID​
:)

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Ver  |   BS Length   |       SI      |         MT-ID         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

​So what difference it is for you ? After all ​this is just binary string
you read from the packet and perform lookup upon.

Btw I am not sure if we need MT-ID so wide so we may have some spare room
for new ideas there :)

r.

On Tue, Oct 21, 2014 at 9:41 AM, IJsbrand Wijnands <[email-masked]> wrote:

> >> I agree with you this is a completely new way to forward and replicate
> multicast packets. Does it help you to think about the ‘generic’ BIER
> encapsulation to be like this? The Table ID is an 20 bit value used as an
> indirection that represents SetID, MT-ID, BitString Length, (and any other
> value you want to add in the future). The data-plane is not overloaded with
> multiple lookups, the Table ID points to the BIFT table that needs to be
> used to forward the packet using the BitString.
> >>
> >>
> >>      0                   1                   2                   3
> >>> Let’s have a look at one possible extreme of the BIER application:
> only one egress PE for a given overlay BUM packet. In this case, we could
> either use the BIER encapsulation by setting only one bit of the BitString
> which is corresponding to that egress PE or use the IP encapsulation with
> the destination being filled with the address of that egress PE.
> >>>
> >>> Or we can think about the BIER functionality from the ingress
> replication perspective: assume an ingress PE needs to replicate n copies
> for a given overlay BUM packet with each destined for a particular egress
> PE. Since  n copies (n<m) need to be forwarded to a given next-hop,  the
> ingress PE decides to “aggregates” that n copies into one copy by listing
> egress PEs for those n copies within one copy.
> >>>
> >>> From the above reasoning, we can find that the BIER is exactly a
> totally-new network layer in which one or more destination addresses could
> be indicated (by the BitString).
> >>>
> >>> Best regards,
> >>> Xiaohu
> >>>
> >>> Regardless of how the alternate is computed, there can still be an
> MPLS label indicating the merge-point; then the existence of a BIER header
> would have to be indicated next on the stack.
> >>> The choice is simple ... you continue into closed and limited data
> plane paradigm or you keep it open. Choice is yours.
> >>>
> >>> I think this comes down to common use-cases and deployments.
> Understanding the technology and problem scope is a primary focus of the
> upcoming BoF.
> >>>
> >>> One clear use-case that maps to a highly deployed case is MPLS for
> MVPN.  Certainly, that seems to be a good motivator.
> >>>
> >>> I can certainly see BIER being useful in the DC case - as I pointed
> out to the NVO3 chairs.  However, I don't see a need to create another full
> >>> I want to add that, even if the topology and SI are encoded in the
> BIER header itself, in case of MPLS based FRR, we still need another label
> to indicate that a BIER header follows.
> >>>
> >>> For that you either use a special label, or just use a regular label
> that also gives you the topology and SI all the time, for the benefits that
> Eric explained below.
> >>>
> >>> Jeffrey
> >>>
> see
> this

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 21 Oct 2014 09:52:02 +0200

Hi Somasundaram,

Of course not,…

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 21 Oct 2014 10:02:29 +0200

Robert,

> But proposed header has exactly 20 bits to use different BIFT too ... it is just they are call differently​: SI + MT-ID​ :) 

Is BS Length not part of it?

> ​So what difference it is for you ? After all ​this is just binary string you read from the packet and perform lookup upon. 
> 
> Btw I am not sure if we need MT-ID so wide so we may have some spare room for new ideas there :) 

Two great question, thank you for asking :-)

By not statically nailing the fields (like you do above), we achieve control-plane separation from the data-plane. You already ask the question if the MT-ID needs to be this wide, we don’t worry about that anymore. Also, what if you want additional fields? Using an MPLS label as an indirection is a very flexible approach. I hope you can see that.

Thx,

Ice.

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 21 Oct 2014 07:50:30 +0000

[Tony said] http://tools.ietf.org/html/rfc1584   Long before most of the router companies in this alias here even existed. I’m sure John will be excited when he gets a call on Nantucket ;-) ;-) Now, those were times when the world was young and we weren’t afraid to haul some _serious_ state around in IGPs ;-) ;-)

--- tony

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 21 Oct 2014 08:08:07 +0000

Hi Ice,

Honestly speaking, it looks like a frog with a tail. In other words, it is on the way towards a complete network layer header.

Best regards,
Xiaohu

> Sent: Tuesday, October 21, 2014 3:35 PM
> To: Xuxiaohu
> Cc: Alia Atlas; Robert Raszuk; Jeffrey (Zhaohui) Zhang; [email-masked]; Eric Rosen
> I agree with you this is a completely new way to forward and replicate multicast
> packets. Does it help you to think about the 'generic' BIER encapsulation to be
> like this? The Table ID is an 20 bit value used as an indirection that represents
> SetID, MT-ID, BitString Length, (and any other value you want to add in the
> future). The data-plane is not overloaded with multiple lookups, the Table ID
> points to the BIFT table that needs to be used to forward the packet using the
> BitString.
> 
> 
>       0                   1                   2                   3
>      ~
> ~
> > Let's have a look at one possible extreme of the BIER application: only one
> egress PE for a given overlay BUM packet. In this case, we could either use the
> BIER encapsulation by setting only one bit of the BitString which is
> corresponding to that egress PE or use the IP encapsulation with the destination
> being filled with the address of that egress PE.
> >
> > Or we can think about the BIER functionality from the ingress replication
> perspective: assume an ingress PE needs to replicate n copies for a given overlay
> BUM packet with each destined for a particular egress PE. Since  n copies (n<m)
> need to be forwarded to a given next-hop,  the ingress PE decides to
> "aggregates" that n copies into one copy by listing egress PEs for those n copies
> within one copy.
> >
> > From the above reasoning, we can find that the BIER is exactly a totally-new
> network layer in which one or more destination addresses could be indicated
> (by the BitString).
> >
> > Best regards,
> > Xiaohu
> >
> > Regardless of how the alternate is computed, there can still be an MPLS label
> indicating the merge-point; then the existence of a BIER header would have to
> be indicated next on the stack.
> > I can certainly see BIER being useful in the DC case - as I pointed out to the
> NVO3 chairs.  However, I don't see a need to create another full overlay
> encapsulation (complete with TTL, QoS, etc.).  One question with BIER is
> whether it is viewed like a pseudo-wire header or a new encapsulation or such?
> I do think there could be a common base and then either an optional first word
> or two, depending.  Taking a look at what type of extension/encapsulation
> would make sense for vxlan sounds interesting - but there are also some change
> control issues for the IETF around vxlan.
> >
> > Regards,
> > Alia
> > Best,
> > R.
> >
> > I want to add that, even if the topology and SI are encoded in the BIER header
> itself, in case of MPLS based FRR, we still need another label to indicate that a
> BIER header follows.
> >
> > For that you either use a special label, or just use a regular label that also gives
> you the topology and SI all the time, for the benefits that Eric explained below.
> >
> > Jeffrey
> >

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Oct 2014 10:14:30 +0200

> Is BS Length not part of it?
​It a length .. you do not perform lookup based on that. I assume you don't
find it that difficult to read arbitrary string after any offset from the
packet - right ?

​

> By not statically nailing the fields (like you do above), we achieve
> control-plane separation from the data-plane.

​LOL .. sorry control plane separation means not muxing N-values into one
value. It means that your control plane procesing happens on different
hardware then your data plane processing. Note that this is nothing new as
such different hardware can be RP and LC which has been done for decades.

> You already ask the question if the MT-ID needs to be this wide, we don’t
> worry about that anymore. Also, what if you want additional fields? Using
> an MPLS label as an indirection is a very flexible approach. I hope you can
> see that.
>

​Ice .. I am not the enemy of indirection. As you know I like L3VPN with
MPLS VPN label over GRE.

For BIER however I see no point of such huge lookup space being used just
to map packets to BIFT tables. Do you really plan ​need of 2^20 tables just
because we already have a lookup mechanism for it in some network gear ?

r.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 21 Oct 2014 10:26:03 +0200

Robert,

> For BIER however I see no point of such huge lookup space being used just to map packets to BIFT tables. Do you really plan ​need of 2^20 tables just because we already have a lookup mechanism for it in some network gear ? 

The key is much smaller as to what you are proposing!

Thx,

Ice.

---

From: Haoweiguo <[email-masked]>
Date: Tue, 21 Oct 2014 11:32:04 +0000

MOSPF is used for constructing shortest-path tree using <source,group> as multicast  forwarding key. It is similar to PIM-SM.
Bidir-PIM is more popular in data center network, it uses share tree model, no <source,group> forwarding state and RFC check is required on each device, so  it  is simpler than PIM-SM or MOSPF. IS-IS extension can be used to replace bidir-PIM to construct bi-direction distribution tree in data center network.
Thanks

weiguo

________________________________
发件人: Antoni Przygienda [[email-masked]]
发送时间: 2014年10月21日 15:50
收件人: Haoweiguo; Alia Atlas; Robert Raszuk
抄送: [email-masked]; IJsbrand Wijnands; Lucy yong; Jeffrey (Zhaohui) Zhang; Xuxiaohu; Eric Rosen
主题: RE: [Bier] 答复: BIER encapsulation

--- tony

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 22 Oct 2014 07:20:35 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, October 21, 2014 3:50 PM
To: IJsbrand Wijnands
Cc: Xuxiaohu; Alia Atlas; Jeffrey (Zhaohui) Zhang; [email-masked]; Eric Rosen
Subject: Re: [Bier] BIER encapsulation

But proposed header has exactly 20 bits to use different BIFT too ... it is just they are call differently
​: SI + MT-ID​
:)

        0                   1                   2                   3

[Xiaohu] Good point.

[Xiaohu] The MT-ID could be used for incremental deployment purpose. For example, only BIER-capable routers are configured as belonging to a particular topology and therefore BIER packets could be forwarded according to that topology’s routing instance. Since the BIER is a totally-new network layer, the capability of incremental deployment should be essential.

Best regards,
Xiaohu

r.

On Tue, Oct 21, 2014 at 9:41 AM, IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>> wrote:
Because it allows you to use more then one BIFT table. Even if you don’t use MT-ID, each SetID have its own BIFT.

On 21 Oct 2014, at 09:39, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

> On Tue, Oct 21, 2014 at 9:35 AM, IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>> wrote:
>> Xiaohu,
>>
>> On 21 Oct 2014, at 08:41, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>>> Cc: Jeffrey (Zhaohui) Zhang; Xuxiaohu; [email-masked]<mailto:[email-masked]>; IJsbrand Wijnands; Eric Rosen

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 22 Oct 2014 08:45:43 +0000

I didn’t want to chime in but this discussion is taking couple of weird’ turns. So

<rant mode=”on” strength=”mild”>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, October 21, 2014 3:50 PM
To: IJsbrand Wijnands
Cc: Xuxiaohu; Alia Atlas; Jeffrey (Zhaohui) Zhang; [email-masked]<mailto:[email-masked]>; Eric Rosen
Subject: Re: [Bier] BIER encapsulation

        0                   1                   2                   3

[Tony said]  yes, a bit is a bit is a bit but the semantics differ.  The ‘fast-path’ is called ‘fast-path’ not because it is fast but it is fast because it operates not on complicated control plane abstractions but on very small mappings (think hashes if you want) of  very ‘context-rich’ information.  More practical: we do not carry things like AS-paths in packet headers for a reason, neither do we DNS names but we carry addresses and when we go really fast labels.  The hierarchy of these things becomes obvious when one debases oneself to read the fundamental paper by J. Schoch “Inter-Network, Naming, Addressing & Routing” from 1978 (gasp, yes, ACM transactions, it’s that far ago some of the most fundamental thinking in networking was done).   And yes, CCN and such jazz tries to turn it upside down & we’ll see how that goes but the B$ in silicon today are optimized for ‘lowest level of abstraction’ and those are labels.  Or thinking in economic terms: the more difficult the fwd’ decision, the more a packet must be worth [or its flow] (someone gotta pay for the work to classify the packet in power, money, time or something else).  If we care full video streams, something like CCN may be a go, if we carry IP or L2 packets like BIER wants to do, com’on, your budget is really, really, really tiny.

Now, if sticking higher levels of abstractions into the fwd’ path seems still like a great idea it may be first but then it bites right back. What if we need more useful info & we run out of bits, longer SI anyone, some ultimate QoS differentiation of 4 bits more in it somehow ? Cannot be done if you try to ‘hack’ 20 bits to carry ‘just what you need’. Either it’s 20 bits & that’s your ‘space’ to map into higher level abstractions & you don’t imply any semantics or you have  a ‘hack’ of having found ’20 bits’ and putting into it ‘what you need’.   Yes, you can always add a TLV into fwd’ path and fwd based on that and it will be really cheap, fast & good. Yes, I’m ironic, it may be fast & good but it will be expensive for a while (until BGates silicon starts to cost c$). Read the economic corollary in paragraph before.

There is a second bite: you are leaking concepts into fwd’ plane ? What does that mean ? Well, what if BIER acquires signaling friends & the BIFT are set-up using not IGP but some  XSVP and that has no concept of MT-ID ? Will you invent a new encapsulation per control plane protocol ? Really ?

So, keep the labels, flat, semantic free in fwd’ path (except denoting really a FEC) and stash all the goodies into control plane, that’s where it belongs. SI s, MT, QoS computations, extended metrics, instances. The role of any control protocol is to carry lots of semantically rich information dis-associating different things you want your network to be & squeeze them into addresses with a simple decision or to go real fast, dumb, flat, small labels with _local_ significance (yepp, that’s why we swap those things).

[Tony said] BIER packets will be ‘forwarded’ using BIFT and not some elaborate control plane criteria. You identify which tree you’re on, then you’re hitting the bitmask flipping, replication and packets go to hit BIFTs on next node(s).

My point overall for the people needing an executive summary, having short attention span or simply getting lost in more elaborate thoughts: stop sticking stuff into fwd’ plane that are control plane abstractions. Flatten those into forwarding decisions and use simple identifiers to distinguish which BIFT you want to hit and nothing else. Labels or something like this, flat, smallish, cheap and locally significant only and ideally one fixed size (or two).  Aaah, you say, MPLS is a luxury we don’t have, ever thought e.g. about the fact that MACs are flat & pretty much locally significant (yes, they’re global for a different purpose than we’re talking here, same MAC on two IP subnets will chuck just fine & there is even a ‘local’ bit if IEEE didn’t regal you with a MA-L). Not saying that’s how it’s supposed to be done but direct thinking from the ‘we need control plane abstractions in the header to make decisions’

</rant>

--- tony

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 22 Oct 2014 10:57:41 +0200

Hi Ice,

So I thought about our discussion on and offline yesterday.

I understand the point and advantages (zero hardware impact) where you are
trying to hash various control plane fields (known today and new in the
future) into single key. I buy it.

But I am not clear why for that you have choosen 20 bits (mpls label) as
opposed to say 32 bits (ipv4 address) ?

Fixed size, exact match, partial support across wide range of network
elements of mpls is much more limiting then variable length, longest match,
structured and supported by any network element bit string. Both lookups
speeds are the same so no advantage there.

Are those 12 bits worth the struggle so much ?

Please explain - thinking openly - what would break if instead of MPLS
label you would use 4 octets lookup to point to internal data structures of
BIER enabled device ? And as you can guess there are really nice ways to
carry such 4 octets today in the packet header without even adding any new
layers :)

Best,
R.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 22 Oct 2014 12:07:21 +0200

Robert,

> I understand the point and advantages (zero hardware impact) where you are trying to hash various control plane fields (known today and new in the future) into single key. I buy it. 

Great.

> But I am not clear why for that you have choosen 20 bits (mpls label) as opposed to say 32 bits (ipv4 address) ? 

First of all, I did not choose 20 bits, I just put the BIER header and the MPLS header together, renaming Label into a Table ID. People seem to get upset if you say your solution requires Labels and I just wanted to show an ‘generic’ encoding that does not uses Labels, of course, this is all just perception.

> 
> Fixed size, exact match, partial support across wide range of network elements of mpls is much more limiting then variable length, longest match, structured and supported by any network element bit string. Both lookups speeds are the same so no advantage there.
> 

In one email you argue 20^2 is way to much, now you’re saying I need 12 bits more. If you can re-use many features that have been developed based on 20 bits (yes, MPLS, like FRR, TE tunnels, SR Tunnels, VPN context), this is worth the struggle!

Now that we agree on the advantages of this ‘indirection’ or ‘key’ forwarding mechanism, do you see why I don’t like the encapsulation as presented in draft-xu- ?

Thx,

Ice.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 22 Oct 2014 10:15:49 +0000

Does it require to allocate a dedicated Ethertype code for the combined header (MPLS label+BIER header)?

Xiaohu

-----Original Message-----
From: IJsbrand Wijnands [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2014 6:07 PM
To: Robert Raszuk
Cc: Xuxiaohu; Alia Atlas; Jeffrey (Zhaohui) Zhang; [email-masked]; Eric Rosen
Subject: Re: [Bier] BIER encapsulation

Robert,

Great.

> But I am not clear why for that you have choosen 20 bits (mpls label) as opposed to say 32 bits (ipv4 address) ? 

First of all, I did not choose 20 bits, I just put the BIER header and the MPLS header together, renaming Label into a Table ID. People seem to get upset if you say your solution requires Labels and I just wanted to show an 'generic' encoding that does not uses Labels, of course, this is all just perception.

> Are those 12 bits worth the struggle so much ?

In one email you argue 20^2 is way to much, now you're saying I need 12 bits more. If you can re-use many features that have been developed based on 20 bits (yes, MPLS, like FRR, TE tunnels, SR Tunnels, VPN context), this is worth the struggle!

Now that we agree on the advantages of this 'indirection' or 'key' forwarding mechanism, do you see why I don't like the encapsulation as presented in draft-xu- ?

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 22 Oct 2014 13:04:40 +0200

Does a (MPLS Label + IPv4/IPv6) require a dedicated Ethertype?

Thx,

Ice.

---

From: "S, Somasundaram (Somasundaram)" <[email-masked]>
Date: Wed, 22 Oct 2014 11:19:10 +0000

Hi Ice,
	Can you explain the other factors that were taken in to consideration other than the indirection factor discussed below that prompted to settle down with this approach?

Regards
Somasundaram

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands
Sent: Wednesday, October 22, 2014 3:37 PM
To: Robert Raszuk
Cc: Jeffrey (Zhaohui) Zhang; Xuxiaohu; [email-masked]; Eric Rosen
Subject: Re: [Bier] BIER encapsulation

Robert,

Great.

Thx,

Ice.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 22 Oct 2014 13:55:41 +0200

Ice,

First of all, I did not choose 20 bits, I just put the BIER header and the
> MPLS header together, renaming Label into a Table ID. People seem to get
> upset if you say your solution requires Labels and I just wanted to show an
> ‘generic’ encoding that does not uses Labels, of course, this is all just
> perception.
>

​It is not only perception.

If this is a label you do not need ethertype, but you need to worry about
different free label ranges available on each platform for BIER. Just like
SR architecture had to waist number of pages on that. ​

​If this is new space then it no longer be behind MPLS ethertype as it
would end up in the lookup into MPLS global table ​of a given node.

> In one email you argue 20^2 is way to much, now you’re saying I need 12
> bits more.

​I only asked what is the envisioned use for 20 bits. You replied that key
will be much smaller without providing any comprehensive comment on the
rest of the bits. ​

> If you can re-use many features that have been developed based on 20 bits
> (yes, MPLS, like FRR, TE tunnels, SR Tunnels, VPN context), this is worth
> the struggle!
>

​This is completely wrong. You are mixing transport layer with application
layer. What FRR has to do with BIER ? Nothing. ​

​I highly hope that whatever header you choose to label your BIER packets
with will be completely transport agnostic and that it can equally well
travel over SR, IPv4, IPv6 or LDP/RSVP-TE MPLS.

​Your and few other comments ​so far do not indicate transport separation
at all. Rather you are inventing new transport which does heavily depends
on mpls forwarding and *current* label space.

Now that we agree on the advantages of this ‘indirection’ or ‘key’
> forwarding mechanism, do you see why I don’t like the encapsulation as
> presented in draft-xu- ?
>

​The draft describes the universal header format. It is not a big problem
to add there (maybe not at the front) hashed key if you prove this is
useful.

But knowing how to hash can equally well be also perform at each BIER
node's data plane without need to carry this verbatim in the packets. ​

​Best,
r.​

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 22 Oct 2014 14:06:54 +0200

Robert,

> If this is a label you do not need ethertype, but you need to worry about different free label ranges available on each platform for BIER. Just like SR architecture had to waist number of pages on that. ​

No! We just allocate a random range from LSD.

> This is completely wrong. You are mixing transport layer with application layer. What FRR has to do with BIER ? Nothing. ​

I suggest you think about this statement for a little bit longer.

> ​I highly hope that whatever header you choose to label your BIER packets with will be completely transport agnostic and that it can equally well travel over SR, IPv4, IPv6 or LDP/RSVP-TE MPLS. 

Yes.

> 
> ​Your and few other comments ​so far do not indicate transport separation at all. Rather you are inventing new transport which does heavily depends on mpls forwarding and *current* label space. 

You almost got it, I’m not inventing anything new, I’m just using MPLS.

> ​The draft describes the universal header format. It is not a big problem to add there (maybe not at the front) hashed key if you prove this is useful. 

You mean something like MPLS?

> 
> But knowing how to hash can equally well be also perform at each BIER node's data plane without need to carry this verbatim in the packets. ​

I guess you did not get it.

Thx,

Ice.