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

Ice, Eric, *:

Inline,

On Tue, Feb 27, 2018 at 06:59:47PM +0100, IJsbrand Wijnands wrote:
> router bier
>  encapsulation non-mpls bsl-sd-si bsl 256
                          ^^^^^^^^^
>   sub-domain 1
>    source loopback 0
>    bift-id auto
     ^^^^^^^^^^^^ probably redundant/default
>   !

Of course, cli is IETF contraband, but: 

Can we not try to overcome Erics concern by making sure the
BIER YANG data model has a mandatory way to provision bift-id's
both via "flat-bift" and "bsl-sd-si". Aka: the "flat-bift"
would the option that (the way i understand it) Eric is concerned
about. Likewise the auto part would be good to describe in the
YANG model (i assume that you somehow try to figure out the max
SI needed, but not quite sure how).

I have always been a fan of first working out the operator
interface and dedude from that the required protocol details.
Not the other way around. Before YANG we're almost not even

allowed to talk about this idea (operator interface not standardized,
go away). With YANG now it seems we do have the chance to also
start doing this in the IETF.

Cheers
    Toerless

>  !
> !
> 
> 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 <erosen@juniper.net> 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.
> > 
> 
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
tte@cs.fau.de