Subject: Re: [Bier] New Version Notification for draft-wang-bier-lite-ospf-extension-01.txt

From: [email-masked]
Date: Wed, 21 Oct 2015 08:47:49 +0800

Dear all, 

  A new draft about how to extend IGP protocol to implement BIER in 
non-MPLS network is proposed, which is also named as BIER-Lite in this 
draft. 
  Wish you can pay attention to this draft and any comments are welcome:) 
  http://tools.ietf.org/id/draft-wang-bier-lite-ospf-extension-01.txt 

Best Wishes, 
Linda Wang

[email-masked] 写于 2015/10/16 16:29:32:

> [email-masked] 
> 2015/10/16 16:29
> 
> 收件人
> 
> "Cui Wang" <[email-masked]>, "Cui Wang" 
> <[email-masked]>, "Zheng Zhang" <[email-masked]>, 
> "Zheng Zhang" <[email-masked]>, 
> 
> 抄送
> 
> 主题
> 
> New Version Notification for draft-wang-bier-lite-ospf-extension-01.txt
> 
> 
> A new version of I-D, draft-wang-bier-lite-ospf-extension-01.txt
> has been successfully submitted by Cui Wang and posted to the
> IETF repository.
> 
> Name:      draft-wang-bier-lite-ospf-extension
> Revision:   01
> Title:      OSPF Extension for BIER-Lite
> Document date:   2015-10-16
> Group:      Individual Submission
> Pages:      13
> URL:            https://www.ietf.org/internet-drafts/draft-wang-
> bier-lite-ospf-extension-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-wang-bier-
> lite-ospf-extension/
> Htmlized:       https://tools.ietf.org/html/draft-wang-bier-lite-
> ospf-extension-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-wang-bier-
> lite-ospf-extension-01
> 
> Abstract:
>    Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is
>    an architecture that provides optimal multicast forwarding through a
>    "BIER domain" without requiring intermediate routers to maintain any
>    multicast related per-flow state.  BIER also does not require any
>    explicit tree-building protocol for its operation.  Currently, the
>    data plane of BIER is apt to use BIER-MPLS encapsulation to transmit
>    multicast traffic.  However, this document tries to propose a
>    solution name BIER-Lite about how to extend OSPF protocol to support
>    BIER forwarding in non-MPLS underlay network instead of MPLS underlay
>    network.
> 
>  
> 
> 
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 21 Oct 2015 01:59:25 +0000

Hi Linda,

Thanks for proposing this draft.

I think it’s worthwhile for the WG to consider the possibility of deploying BIER in non-MPLS networks (e.g., a data center network where VXLAN/NVGRE is deployed). IMHO, one major reason for those DC operators, especially non-SP DC operators to prefer VXLAN/NVGRE to MPLS-in-UDP/MPLS-in-GRE in their data center networks is that they are unfamiliar with MPLS or dislike MPLS instinctively. Honestly speaking, I couldn’t think of any technical advantage of using VXLAN/NVGRE instead of MPLS-in-UDP/MPLS-in-GRE, especially in the hybrid cloud scenario where it’s much necessary to interconnect the DC VPN with the WAN VPN (i.e., MPLS-based VPN) in a scalable way (i.e., by using inter-AS option B). When deploying BIER in the above networks, those DC operators are familiar with MPLS and advocate MPLS all of a sudden. Doesn’t it sound strange?

Best regards,
Xiaohu

From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 21, 2015 8:48 AM
To: [email-masked]
Subject: Re: [Bier] New Version Notification for draft-wang-bier-lite-ospf-extension-01.txt

Dear all,

 A new draft about how to extend IGP protocol to implement BIER in non-MPLS network is proposed, which is also named as BIER-Lite in this draft.
  Wish you can pay attention to this draft and any comments are welcome:)
 http://tools.ietf.org/id/draft-wang-bier-lite-ospf-extension-01.txt

Best Wishes,
Linda Wang

[email-masked]<mailto:[email-masked]> 写于 2015/10/16 16:29:32:

> [email-masked]<mailto:[email-masked]>
> 2015/10/16 16:29
>
> 收件人
>
> "Cui Wang" <[email-masked]<mailto:[email-masked]>>, "Cui Wang"
> <[email-masked]<mailto:[email-masked]>>, "Zheng Zhang" <[email-masked]<mailto:[email-masked]>>,
> "Zheng Zhang" <[email-masked]<mailto:[email-masked]>>,
>
> 抄送
>
> 主题
>
> Please note that it may take a couple of minutes from the time of submission

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 21 Oct 2015 09:06:41 -0700

On 10/20/15 6:59 PM, Xuxiaohu wrote:
> I think it’s worthwhile for the WG to consider the possibility of 
> deploying BIER in non-MPLS networks (e.g., a data center network where 
> VXLAN/NVGRE is deployed). IMHO, one major reason for those DC 
> operators, especially non-SP DC operators to prefer VXLAN/NVGRE to 
> MPLS-in-UDP/MPLS-in-GRE in their data center networks is that they are 
> unfamiliar with MPLS or dislike MPLS instinctively. Honestly speaking, 
> I couldn’t think of any technical advantage of using VXLAN/NVGRE 
> instead of MPLS-in-UDP/MPLS-in-GRE, especially in the hybrid cloud 
> scenario where it’s much necessary to interconnect the DC VPN with the 
> WAN VPN (i.e., MPLS-based VPN) in a scalable way (i.e., by using 
> inter-AS option B). When deploying BIER in the above networks, those 
> DC operators are familiar with MPLS and advocate MPLS all of a sudden. 
> Doesn’t it sound strange?
>

When a data center is already using a Virtualization Manager to set up 
VLANs or VxLANs it is safe to bet that some
annoying little app that wants to do multicasting will simply be 
ignored. They will certainly not rewrite their entire
infrastructure to use MPLS.

Already having things working without MPLS is a horrendous technical 
advantage.

Is there anything difficult in mapping a BIER sub-domain to an already 
existing VXLAN or VLAN?

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 21 Oct 2015 19:20:21 +0200

Hi Caitlin,

> annoying little app that wants to do multicasting will simply be ignored. They will certainly not rewrite their entire

Why would you assume unicast has to change in order to deploy BIER with MPLS?

> 
> Already having things working without MPLS is a horrendous technical advantage.

BIER uses MPLS as indirection into a BIFT, that’s it. The allocation and distribution of that ‘Label’, is all within the boundaries of the BIER procedures we defined. Effectively we are not doing any MPLS based forwarding. Would it help is we rename the 20 bits into 'BIFT ID'?

Thx,

Ice.

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 21 Oct 2015 12:41:10 -0700

> Why would you assume unicast has to change in order to deploy BIER with MPLS?
Anyone writing or managing a cluster-wide network/virtualization 
management tool will want multicast
to be nothing more than the logical union of unicast addressing. If I 
move a VM to a new host it is hard
enough to logically rewire the network so that the unicast traffic 
reaches the new location. The last thing
that would be wanted would be to have to separately rewire the network 
for multicast.

Of course it is most accurate just to say that the VLAN/VXLAN is what is 
rewired, and both unicast and
multicast addressing conforms to the new VLAN/VXLAN wiring.

> BIER uses MPLS as indirection into a BIFT, that’s it. The allocation and distribution of that ‘Label’, is all within the boundaries of the BIER procedures we defined. Effectively we are not doing a…
Don't analyze this in the context of BIER. Cluster management exists 
independently of BIER.
If you want it to change you'd need an explanation that made sense 
without having to explain
BIER internals. If support for multicast is too complex their solution 
will be to broadcast all
multicast packets to the entire VLAN/VXLAN.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 22 Oct 2015 10:46:26 +0200

Hi Linda,

I’ve read through this draft, but it is not clear to me what your proposal is how to encode the BitString in the IP packet. There are many different ways to do it, GRE, IPIP, UDP, etc… Ultimately, the encapsulation is only relevant from node to node. The actual forwarding of the packet is based on the BitString, not the encapsulation. Why do you consider this to be more ‘lite’ over MPLS? 

Thx,

Ice.

> On 21 Oct 2015, at 02:47, [email-masked] wrote:
> 
> 
> Dear all, 
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: [email-masked]
Date: Thu, 22 Oct 2015 17:26:34 +0800

Hi Ice,

  In this proposal, the BIER header isn't encapsulated in the IP packet. 
Instead, the BIER header is between the Ethernet Header and the IP header. 
As for the Ether Type, here we can use 0101 to identify the following is 
BIER header.

  Thanks for your comments :)

Best Wishes,
Linda

Hi Linda,

I’ve read through this draft, but it is not clear to me what your 
proposal is how to encode the BitString in the IP packet. There are many 
different ways to do it, GRE, IPIP, UDP, etc… Ultimately, the 
encapsulation is only relevant from node to node. The actual forwarding of 
the packet is based on the BitString, not the encapsulation. Why do you 
consider this to be more ‘lite’ over MPLS? 

Thx,

Ice.

> > New Version Notification for 
draft-wang-bier-lite-ospf-extension-01.txt 
submission

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 22 Oct 2015 11:43:28 +0200

Linda,

>   In this proposal, the BIER header isn't encapsulated in the IP packet. Instead, the BIER header is between the Ethernet Header and the IP header. As for the Ether Type, here we can use 0101 to identify the following is BIER header. 

Is this documented in your draft?

The BIER header you are referring to, is that the MPLS BIER header? If you omit the MPLS label, there is no need for TTL and TOS?

Thx,

Ice.

---

From: [email-masked]
Date: Fri, 23 Oct 2015 09:08:17 +0800

Ice,

  Sorry for not documenting this in this draft, maybe I should add a 
section to describe this clearly :)

  As for the BIER header in the BIER-Lite scenario, we need redefine a new 
BIER header, which includes some more parameters,such as BSL,sub-domain 
and SI information as well as TTL and TOS information,to the BIER header 
defined in BIER-MPLS draft. 

  Thanks,

Best wishes,
Linda

Linda,

The BIER header you are referring to, is that the MPLS BIER header? If you 
omit the MPLS label, there is no need for TTL and TOS?

Thx,

Ice.

submission

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 23 Oct 2015 10:47:10 +0200

Linda,

>   Sorry for not documenting this in this draft, maybe I should add a section to describe this clearly :) 

This is an OSPF draft, I would not expect you to document it there ;-)

>  As for the BIER header in the BIER-Lite scenario, we need redefine a new BIER header, which includes some more parameters,such as BSL,sub-domain and SI information as well as TTL and TOS information,to the BIER header defined in BIER-MPLS draft. 

You also have to allocate a new ethertype, like IPv4, IPv6 and MPLS since they all have their own. You can’t rely on the first nibble as a differentiator. But before you do this, why do you think this is any simpler compared to using a MPLS label, that sits in front of the MPLS BIER header? If the BSL, sub-domain and SI will each get their own field, you made it more complicated to process in forwarding. The advantage of MPLS is that the 20 bit value is an indirection that indirectly encodes the SI, sub-domain and BSL. So with a single lookup in forwarding you can find the table you need to use to forward the packet.

Even if there would be a use-case to define a new ethertype to encode a BIER header, I would push for a similar approach to MPLS, having an indirection that identifies the BIFT table. What have we gained if we would do that? I think the only issue we have MPLS is the name ;-)

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 23 Oct 2015 11:13:46 +0200

Caitlin,

> Anyone writing or managing a cluster-wide network/virtualization management tool will want multicast
> to be nothing more than the logical union of unicast addressing. If I move a VM to a new host it is hard

BIER is a perfect fit for that as the Bits in the packet follow unicast routing.

> enough to logically rewire the network so that the unicast traffic reaches the new location. The last thing
> that would be wanted would be to have to separately rewire the network for multicast.

I don’t think that will be necessary. If you allocate your IP addresses nicely, you can even derive the BFR-id from the lower 2 octets of the IP address, so its always in sync. 

> 
> Of course it is most accurate just to say that the VLAN/VXLAN is what is rewired, and both unicast and
> Don't analyze this in the context of BIER. Cluster management exists independently of BIER.
> If you want it to change you'd need an explanation that made sense without having to explain
> BIER internals. If support for multicast is too complex their solution will be to broadcast all

Yes, that is why many people like BIER, it much simpler compared to traditional multicast. 

Thx,

Ice.

---

From: [email-masked]
Date: Fri, 23 Oct 2015 17:51:40 +0800

Dear Ice,

  First, I would like to explain the question about why I think BIER-Lite 
is simpler compared to using a MPLS label, that sits in front of the MPLS 
BIER header?

    In fact, I have two understanding ways about BIER-Lite:
    1. BIER-Lite is apt to be used in the non-MPLS network . In other 
words, BIER-Lite is a complementary of BIER-MPLS solution. If the network 
has MPLS capability, using MPLS-BIER is great.   Otherwise, considering 
using BIER-Lite may be a choice. As you mentioned, the advantage of 
BIER-MPLS label is an indirection that indirectly encodes the SI, 
sub-domain and BSL. So with a single lookup in forwarding you can find the 
table you need to use to forward the packet. But in fact, as for advanced 
chips, it's not a problem to hit the BIFT once according to three direct 
parameters(the SI, sub-domain and BSL.) So the forwarding in BIER-Lite 
seems not the key issue.
   2. The other understanding way is that, we can use BIER-Lite in simple 
environment(such as relatively small data centers), where only one 
sub-domain, only on Set, even if only one BSL. Under this environment, 
operators can deploy BIER-Lite to implement BIER. 

  Thanks,

Best Wishes
Linda,

"BIER" <[email-masked]> 写于 2015/10/23 16:47:10:

> IJsbrand Wijnands <[email-masked]> 
> 发件人:  "BIER" <[email-masked]>
> 
> 2015/10/23 16:47
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> "[email-masked]" <[email-masked]>, BIER <[email-masked]>
> 
> 主题
> 
> Re: [Bier] New Version Notification for draft-wang-bier-lite-ospf-
> extension-01.txt
> 
> Linda,
> 
> >  As for the BIER header in the BIER-Lite scenario, we need 
> redefine a new BIER header, which includes some more parameters,such
> as BSL,sub-domain and SI information as well as TTL and TOS 
> information,to the BIER header defined in BIER-MPLS draft. 
> 
> You also have to allocate a new ethertype, like IPv4, IPv6 and MPLS 
> since they all have their own. You can’t rely on the first nibble as
> a differentiator. But before you do this, why do you think this is 
> any simpler compared to using a MPLS label, that sits in front of 
> the MPLS BIER header? If the BSL, sub-domain and SI will each get 
> their own field, you made it more complicated to process in 
> forwarding. The advantage of MPLS is that the 20 bit value is an 
> indirection that indirectly encodes the SI, sub-domain and BSL. So 
> with a single lookup in forwarding you can find the table you need 
> to use to forward the packet.
> 
> Even if there would be a use-case to define a new ethertype to 
> encode a BIER header, I would push for a similar approach to MPLS, 
> having an indirection that identifies the BIFT table. What have we 
> gained if we would do that? I think the only issue we have MPLS is 
> the name ;-)
> 
> Thx,
> 
> Ice.
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 23 Oct 2015 12:16:40 +0200

Hi Linda,

>     1. BIER-Lite is apt to be used in the non-MPLS network . In other words, BIER-Lite is a complementary of BIER-MPLS solution. If the network has MPLS capability, using MPLS-BIER is great.   Otherwise, considering using BIER-Lite may be a choice. As you mentioned, the advantage of BIER-MPLS label is an indirection that indirectly encodes the SI, sub-domain and BSL. So with a single lookup in forwarding you can find the table you need to use to forward the packet. But in fact, as for advanced chips, it's not a problem to hit the BIFT once according to three direct parameters(the SI, sub-domain and BSL.) So the forwarding in BIER-Lite seems not the key issue. 

Sure, but hard coding these fields is not very flexible for HW, what happens if we want to increase a field size or add a new one?

>    2. The other understanding way is that, we can use BIER-Lite in simple environment(such as relatively small data centers), where only one sub-domain, only on Set, even if only one BSL. Under this environment, operators can deploy BIER-Lite to implement BIER. 

The only different with MPLS is that we allocate a 20 bit value and announce it in the IGP. The IGP announcement does not go away in your proposal as you still announce the BIER capability, SI and Sub-domain. The MPLS label is dynamically allocated, an operator does not have to assign it. Forwarding needs to do a looking on either a 20 bit value with MPLS or a 3 tuple in your proposal to find the BIFT. Removing the 20 bit value from the IGP announcement does not make it ‘lite’..

Thx,

Ice.

---

From: [email-masked]
Date: Mon, 26 Oct 2015 11:49:26 +0800

Dear Ice，

 Thanks very much. Please see inline :)

Yours,
Linda Wang

Hi Linda,

Sure, but hard coding these fields is not very flexible for HW, what 
happens if we want to increase a field size or add a new one?

//Linda: Good consideration:) But on the other hand, until now these 3 
tuples are considered comprehensively for the BIER forwarding according to 
the BIER-arch. Once there requires a new one, I guess there may be a big 
revolution for BIER. 

>    2. The other understanding way is that, we can use BIER-Lite in 
simple environment(such as relatively small data centers), where only one 
sub-domain, only on Set, even if only one BSL. Under this environment, 
operators can deploy BIER-Lite to implement BIER. 

The only different with MPLS is that we allocate a 20 bit value and 
announce it in the IGP. The IGP announcement does not go away in your 
proposal as you still announce the BIER capability, SI and Sub-domain. The 
MPLS label is dynamically allocated, an operator does not have to assign 
it. Forwarding needs to do a looking on either a 20 bit value with MPLS or 
a 3 tuple in your proposal to find the BIFT. Removing the 20 bit value 
from the IGP announcement does not make it ‘lite’..

//Linda: This understanding way just supposes the simplest case:) In this 
case, the whole BIER-MPLS Encapsulation sub-TLV can be removed. 
Additionally, when each BFR supports several BSL, then BIER-MPLS 
Encapsulation sub-TLV will appear several times. But if there has 
BIER-Lite, not just save 20 bits :) So, I try to say BIER-Lite is a 
relatively 'lite' non-MPLS solution :)

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 26 Oct 2015 12:21:45 +0100

Dear Linda,

> //Linda: This understanding way just supposes the simplest case:) In this case, the whole BIER-MPLS Encapsulation sub-TLV can be removed. Additionally, when each BFR supports several BSL, then BIER-MPLS Encapsulation sub-TLV will appear several times. But if there has BIER-Lite, not just save 20 bits :) So, I try to say BIER-Lite is a relatively 'lite' non-MPLS solution :) 

I think it is misleading to call this BIER lite, just based on the fact you are not including the MPLS TLV in OSPF. I don’t think anybody considers carrying the MPLS TLV in OSPF as heavy in any way ;-)

Thx,

Ice.

---

From: [email-masked]
Date: Wed, 28 Oct 2015 10:04:02 +0800

Dear Ice,

  Thanks for your patient explanation :) 
  In fact, I totally agree that BIER-MPLS using MPLS label to lookup BIFT 
table is a perfect solution.

  Here, about BIER-Lite, it is just another choice for some operators who 
would like to run native IP network. Maybe it is not exactly correct to 
call this solution BIER-Lite, but the purpose of this solution, as you 
know, just for non-MPLS network. It is not MUST required to carry BSL 
information together with MPLS label information. In non-MPLS network, it 
seems acceptable to carry BSL information together with BIER info sub-TLV 
instead. So I propose to carry BSL information in BIER info sub-TLV. If 
this solution is worthy discussing, maybe we can change the name BIER-Lite 
to another more accurate one :)

  Thanks :)

Yours,
Linda Wang

Dear Linda,

> //Linda: This understanding way just supposes the simplest case:) In 
this case, the whole BIER-MPLS Encapsulation sub-TLV can be removed. 

I think it is misleading to call this BIER lite, just based on the fact 
you are not including the MPLS TLV in OSPF. I don’t think anybody 
considers carrying the MPLS TLV in OSPF as heavy in any way ;-)

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 28 Oct 2015 10:16:05 +0100

Hi Linda,

>   In fact, I totally agree that BIER-MPLS using MPLS label to lookup BIFT table is a perfect solution. 

No problem :-).

>   Here, about BIER-Lite, it is just another choice for some operators who would like to run native IP network. Maybe it is not exactly correct to call this solution BIER-Lite, but the purpose of this solution, as you know, just for non-MPLS network. It is not MUST required to carry BSL information together with MPLS label information. In non-MPLS network, it seems acceptable to carry BSL information together with BIER info sub-TLV instead. So I propose to carry BSL information in BIER info sub-TLV. If this solution is worthy discussing, maybe we can change the name BIER-Lite to another more accurate one :) 

Its probably good to checkout below draft first.

https://tools.ietf.org/id/draft-ietf-rtgwg-dt-encap-00.txt

Thx,

Ice.

---

From: Stig Venaas <[email-masked]>
Date: Sat, 31 Oct 2015 18:12:00 -0700

I think it is useful to allow for BIER in non-MPLS networks, but one
could still for efficiency use 20-bit fields where their meaning is
defined by what is announced in the IGP. One could call them MPLS
labels or something else, it doesn't matter. It wouldn't be MPLS
forwarding, just a compact encoding. One question perhaps though, is
whether it is useful in some cases to encode this information
directly, rather than the indirection which requires the additional
information in the IGP, or other means.

Stig