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

[Eric C Rosen <[e-mail]>]

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.


On 2/27/2018 12:59 PM, IJsbrand Wijnands wrote:
> 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 <[e-mail]> wrote:
>>
>> 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.
>>