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

[IJsbrand Wijnands <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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,
>>> 
>>> 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.
>>>> 
>> 
>