Subject: [Bier] Call for adoption: draft-wijnandsxu-bier-non-mpls-bift-encoding-01

From: Greg Shepherd <[email-masked]>
Date: Mon, 26 Feb 2018 10:07:05 -0800

In Singapore we had solid support to
adopt draft-wijnandsxu-bier-non-mpls-bift-encoding as a WG draft.

This is a call to the list for adoption. Please read and reply with/without
support to this thread:

https://datatracker.ietf.org/doc/draft-wijnandsxu-bier-non-mpls-bift-encoding/

Thanks,
Greg

---

From: Xiejingrong <[email-masked]>
Date: Mon, 26 Feb 2018 23:53:05 +0000

support.

--------------------------------------------------
XieJingrong
发件人：Greg Shepherd
收件人：BIER WG,
时间：2018-02-27 02:15:19
主 题：[Bier] Call for adoption: draft-wijnandsxu-bier-non-mpls-bift-encoding-01

In Singapore we had solid support to adopt draft-wijnandsxu-bier-non-mpls-bift-encoding as a WG draft.

This is a call to the list for adoption. Please read and reply with/without support to this thread:

Thanks,
Greg

---

From: <[email-masked]>
Date: Tue, 27 Feb 2018 08:30:43 +0800 (CST)

I have read this draft and support the adoption.

Thanks,

Sandy

原始邮件

发件人：GregShepherd <[email-masked]>
收件人：BIER WG <[email-masked]>
日 期 ：2018年02月27日 02:07
主 题 ：[Bier] Call for adoption:draft-wijnandsxu-bier-non-mpls-bift-encoding-01

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

Thanks,
Greg

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 27 Feb 2018 00:32:01 +0000

Support, thanks!

Regards,
Hooman

Sent from mobile

On Feb 26, 2018, at 1:07 PM, Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 27 Feb 2018 04:10:12 +0000

Support.

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Monday, February 26, 2018 1:07 PM
To: BIER WG <[email-masked]>
Subject: [Bier] Call for adoption: draft-wijnandsxu-bier-non-mpls-bift-encoding-01

https://datatracker.ietf.org/doc/draft-wijnandsxu-bier-non-mpls-bift-encoding/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwijnandsxu-2Dbier-2Dnon-2Dmpls-2Dbift-2Dencoding_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=X98m4w5Xp6E8vTLd1JVSD3K9Cvbl25kdn1Q_fZM7ipk&s=tMhEiZro21ujaB7gGj-zmUCiy56HbSj5eyDbmIfTcCA&e=>

Thanks,
Greg

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 26 Feb 2018 20:57:22 -0800

Yes/support 

Regards,
Jeff

> On Feb 26, 2018, at 10:07, Greg Shepherd <[email-masked]> wrote:
>

---

From: Senthil Dhanaraj <[email-masked]>
Date: Tue, 27 Feb 2018 05:43:40 +0000

Support !

Thanks,
Senthil

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: 26 February 2018 23:37
To: BIER WG <[email-masked]>
Subject: [Bier] Call for adoption: draft-wijnandsxu-bier-non-mpls-bift-encoding-01

Thanks,
Greg

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 27 Feb 2018 13:10:56 +0000

Support.

Regards,
Nagendra

From: BIER <[email-masked]> on behalf of Greg Shepherd <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Monday, February 26, 2018 at 1:07 PM
To: BIER WG <[email-masked]>
Subject: [Bier] Call for adoption: draft-wijnandsxu-bier-non-mpls-bift-encoding-01

Thanks,
Greg

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 27 Feb 2018 09:58:45 -0500

I am strongly opposed to the adoption of this draft.

The premise of the draft is that in non-MPLS networks, operators may 
want to assign a domain-wide unique BIFT-id that denotes, in every BFR, 
the BIFT associated with a given <SD,SI,BSL> triple.

That may be true.  However, there are many procedures that can be used 
to assign domain-wide unique BIFT-ids.  There is no reason for the WG to 
give the appearance of endorsing any one procedure over any of the 
thousands of others.  This is really a decision for the network 
operators.  So I think the document is not very useful.

I do however think the document is harmful.  It will inevitably result 
in the deployment of software (if not hardware) that cannot process 
non-MPLS BIER packets in which the BIFT-id is not formed according to 
the rules of this draft.

Yes, yes, the draft says that the use of this encoding is OPTIONAL, and 
the draft is merely Informational.  That won't help us much when some 
implementation (either from a vendor, or open source) gets deployed that 
requires the use of this encoding.

Drafts that are harmful but not useful should not be adopted by the WG.

If this draft proceeds, I suggest it be turned into an Independent 
Submission, so that it can be made clear that the draft just describes a 
suggestion by the authors.

On 2/26/2018 1:07 PM, Greg Shepherd wrote:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwijnandsxu-2Dbier-2Dnon-2Dmpls-2Dbift-2Dencoding_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=l-KKk7BthqSx7OjcMbxS5nkQZLR40fjA3UQvFQzbEas&s=jcUd-KEqRjNnt4plMdrqae2oeOhQSHIV_oZGcxtxnrg&e=>
>
> Thanks,
> Greg
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=l-KKk7BthqSx7OjcMbxS5nkQZLR40fjA3UQvFQzbEas&s=AjVaQdEtidRkJYHuMaOE3AynPR5gmY4zjT7WulICH1Q&e=

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 27 Feb 2018 07:42:33 -0800

<individual mode = "technical gadfly">

Interesting take

a) The observation that this is just _one_ possible mapping  from
<SD,SI,BSL> to BIFT-id is correct but IMO acknowledged in the abstract and
intro. Albeit a section may be in order explaining
* emphasis that completely different mappings are possible and equivalently
valid
* problems should such different mappings be deployed
* emphasis that introducing such a mapping may prevent correct functioning
of deployments where some subdomains are IGP signalled (dynamic downstream
values) and some use this mapping. Not a likely deployment maybe but when
offering people a sharp stick it helps to emphasize  the pointed ends.
b) I agree that having people build HW that is specialized to just process
this one mapping and nothing else would be quite undesirable for BIER but
if this is not a standards track document I don't know how we would have
any influence on that. Leaving this kind of stuff in the dark where many do
it but it's not documented is arguably worse than having it documented with
proper yellow/red stickers saying "it's gonna hurt" ...

So, not taking any stance, just helping to explore the space ...

And my usual meta-quip I cannot resist: "This being a somewhat dirty
shortcut offered it's worth to note that such shortcuts stay dirty long
after they have been short" ;-)

</individual>

On Tue, Feb 27, 2018 at 6:58 AM, Eric C Rosen <[email-masked]> wrote:

> The premise of the draft is that in non-MPLS networks, operators may want
> to assign a domain-wide unique BIFT-id that denotes, in every BFR, the BIFT
> associated with a given <SD,SI,BSL> triple.
>
> That may be true.  However, there are many procedures that can be used to
> assign domain-wide unique BIFT-ids.  There is no reason for the WG to give
> the appearance of endorsing any one procedure over any of the thousands of
> others.  This is really a decision for the network operators.  So I think
> the document is not very useful.
>
> I do however think the document is harmful.  It will inevitably result in
> the deployment of software (if not hardware) that cannot process non-MPLS
> BIER packets in which the BIFT-id is not formed according to the rules of
> this draft.
>
> BIER mailing [email-masked]://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=l-KKk7BthqSx7OjcMbxS5nkQZLR40fjA3UQvFQzbEas&s=AjVaQdEtidRkJYHuMaOE3AynPR5gmY4zjT7WulICH1Q&e=
>
>
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 27 Feb 2018 18:25:19 +0100

Eric,

Thanks for the comments.

> That may be true.  However, there are many procedures that can be used to assign domain-wide unique BIFT-ids.  There is no reason for the WG to give the appearance of endorsing any one procedure over any of the thousands of others.  This is really a decision for the network operators.  So I think the document is not very useful.

This is indeed a decision that is made by the operator on how to assign a BIFT-id to the <SD,SI,BSL> triple. It is perfectly valid for operator to do exactly what is described in this draft (encode <SD,SI,BSL> into the BIFT), without having this draft. Documenting one mechanism where we take the triple and auto-generate a BIFT-id I think is useful and simplifies the OAM procedures. If we want to be interoperable among different vendors, I think it is good to have this documented.

> I do however think the document is harmful.  It will inevitably result in the deployment of software (if not hardware) that cannot process non-MPLS BIER packets in which the BIFT-id is not formed according to the rules of this draft.

I don’t think there is a benefit for treating the 20 bit BIFT-id any different than a 20bit value, so I’m less concerned.

> 
> Yes, yes, the draft says that the use of this encoding is OPTIONAL, and the draft is merely Informational.  That won't help us much when some implementation (either from a vendor, or open source) gets deployed that requires the use of this encoding.  
> 

Not having to manage the BIFT-id assignments is useful to the operators I think.

> If this draft proceeds, I suggest it be turned into an Independent Submission, so that it can be made clear that the draft just describes a suggestion by the authors.

As long as we get something posted and we can be interoperable I’m good. Although I don’t really think it going to matter to implementors what the official status of the document is. It will not prevent them from mis-behaving if they really want to.

Thx,

Ice.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 27 Feb 2018 12:46:56 -0500

On 2/27/2018 12:25 PM, IJsbrand Wijnands wrote:
> If we want to be interoperable among different vendors, I think it is good to have this documented.

This is the sort of statement that really worries me.  What is the 
interoperability issue?  As long as a vendor allows the assignment of 
BIFT-ids, interoperability should be possible without the need for any 
particular suggested way of constructing the BIFT-ids.

I'm not sure we can say both that the draft is informational, and that 
it is needed for multi-vendor interoperability.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 27 Feb 2018 18:59:47 +0100

Eric,

Maybe a configuration example helps:

Consider the below configuration:

router bier
 encapsulation non-mpls bsl 256
  sub-domain 1
   source loopback 0
   bift-id auto
  !
 !
!

I would think that such configuration is the minimum required on every BIER router (unless there are default that don’t need to be required) independent of the vendor.

Based on the above we can generate a BIFT-id following the draft proposal. Two different vendors having BIER configured will be interoperable because they generate the same BIFT-id, without having to configure it.

It is also possible to configure:

router bier
 encapsulation non-mpls bsl 256
  sub-domain 1
   source loopback 0
   bift-id 10000
  !
 !
!

Now the operator needs to manage value ‘10000’ and make sure its configure on every router the same.

Thx,

Ice.

> On 27 Feb 2018, at 18:46, Eric C Rosen <[email-masked]> wrote:
> 
> This is the sort of statement that really worries me.  What is the interoperability issue?  As long as a vendor allows the assignment of BIFT-ids, interoperability should be possible without the need for any particular suggested way of constructing the BIFT-ids.
> 
> I'm not sure we can say both that the draft is informational, and that it is needed for multi-vendor interoperability.
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 27 Feb 2018 10:00:23 -0800

Hi Greg, et. al,
read the draft. Well-written and addresses practical technical case.

yes/support the WG adoption.

Regards,
Greg

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 27 Feb 2018 20:57:43 +0100

Eric,

> What you're showing below is not a multi-vendor interoperability issue, it's a provisioning issue.    The BIFT-id is only one of 

I agree its provisioning issue, but that does not mean there is no multi-vendor angle here. Every vendor that supports “bift-id auto” needs to encode it the same way.

> several parameters that need to be provisioned, and if the provisioning system cannot manage the BIFT-ids, it's hard to see how it can
>  manage the provisioning of the BFR-prefixes and BSLs.   To me, this seems a minor problem when compared to the possibility of an implementation that only works when the BIFT-id is constructed according to the algorithm of this draft.

On the other hand, there is less risk of mis-configuration because its done through an algorithm :-).

Thx,

Ice.

> 
> 
> On 2/27/2018 12:59 PM, IJsbrand Wijnands wrote:
>> Eric,
>>

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 27 Feb 2018 14:32:58 -0500

What you're showing below is not a multi-vendor interoperability issue, 
it's a provisioning issue.    The BIFT-id is only one of several 
parameters that need to be provisioned, and if the provisioning system 
cannot manage the BIFT-ids, it's hard to see how it can manage the 
provisioning of the BFR-prefixes and BSLs.   To me, this seems a minor 
problem when compared to the possibility of an implementation that only 
works when the BIFT-id is constructed according to the algorithm of this 
draft.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 28 Feb 2018 10:33:26 +0800

Hi Eric,
Thanks for your comments first of all.
It's true that BFR-prefixes and BSLs would have to be provisioned. However, wouldn't it be better to automatically generate the BIFT-ids if possible?
Best regards,Xiaohu
------------------------------------------------------------------发件人：Eric C Rosen <[email-masked]>发送时间：2018年2月28日(星期三) 04:35收件人：IJsbrand Wijnands <[email-masked]>抄　送：gjshep <[email-masked]>; BIER WG <[email-masked]>主　题：Re: [Bier] Call for adoption: draft-wijnandsxu-bier-non-mpls-bift-encoding-01
What you're showing below is not a multi-vendor interoperability issue, 
it's a provisioning issue.    The BIFT-id is only one of several 
parameters that need to be provisioned, and if the provisioning system 
cannot manage the BIFT-ids, it's hard to see how it can manage the 
provisioning of the BFR-prefixes and BSLs.   To me, this seems a minor 
problem when compared to the possibility of an implementation that only 
works when the BIFT-id is constructed according to the algorithm of this 
draft.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 28 Feb 2018 10:32:44 +0100

Eric,

I thought a little more about it and the following occurred to me.

How the non-MPLS encoding is used/provisioned is not fully specified with regards to the IGP drafts. This is something that still need to be done. I don’t expect (although it could) static BFR-id to Prefix mappings to be configured on every BIER node, so it makes perfect sense to use the IGPs for that. That brought me to the topic of the SI. The BIER encapsulation RFC does not spell out that for non-MPLS encapsulation there is an automatic way to translate the BFR-id into a SI and into a BIFT-id. For MPLS we have the Label range for it.

Would it help if we add an other encoding to draft to allow a Provisioned BIFT-Id (PBI) with space to embed the SI? So the PBI is in the range of 0x000 - 0xFFF?

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          PBI          |       SI      | TC  |S|       TTL     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |-------- 20 bit BIFT-id Field ---------|

It will still be up to the operator to determine which mechanism to use and it will make clear to the implementors there are different ways to encode the BIFT-id, so no assumptions can be made how to parse it.

Thx,

Ice.

> On 27 Feb 2018, at 20:57, IJsbrand Wijnands <[email-masked]> wrote:
> 
> Eric,
>

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 28 Feb 2018 14:06:29 -0500

It seems that there are a few details to pin down regarding the 
provisioning model used for assigning BIFT-ids in non-MPLS networks, and 
about the need (or lack of need) for further BIER-specific IGP 
extensions to signal information about the BIFT-ids.

Isn't it premature to be recommending algorithmic encodings before we 
understand the bigger picture?

I do like the idea though of specifying more than one way of structuring 
the BIFT-id, that makes it slightly less likely that someone will burn 
any particular structure into their ASICs.

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 28 Feb 2018 14:15:12 -0500

On 2/27/2018 9:33 PM, 徐小虎(义先) wrote:
> It's true that BFR-prefixes and BSLs would have to be provisioned. 
> However, wouldn't it be better to automatically generate the BIFT-ids 
> if possible?

Sure, other things being equal.  But there are two things to be considered:

1. Should the algorithmic generation be done by each node, or is it 
something that is better done by the provisioning system that creates 
the configuration scripts?

2. Are there likely to be unintended consequences?

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 28 Feb 2018 20:45:16 +0100

Eric,

> It seems that there are a few details to pin down regarding the provisioning model used for assigning BIFT-ids in non-MPLS networks, and about the need (or lack of need) for further BIER-specific IGP extensions to signal information about the BIFT-ids.

Agreed.

> Isn't it premature to be recommending algorithmic encodings before we understand the bigger picture?

I think its orthogonal.

> I do like the idea though of specifying more than one way of structuring the BIFT-id, that makes it slightly less likely that someone will burn any particular structure into their ASICs.

Ok, cool.

Thx,

Ice.