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

[Toerless Eckert <[e-mail]>]

On Tue, Mar 06, 2018 at 05:13:15PM -0800, Tony Przygienda wrote:
> "every encaps needs a BIFT-id YANG element which is writeable" and yes, I
> mean MPLS as well. I can
> very well imagine peiople running MPLS encaps without IGP signalling but
> setting
> fixed values.  Known by cool names like SRGB and stuff ;-)  As side note: I
> also think that
> BIFT elements should be supported as optionally Yang writable so people can
> download
> full off-line computed BIFTs if they choose.  Whether we have to make it a
> SHOULD or a
> MUST (well, that's difficult in models, probably best expressed by whole
> BIFT Yang
> branch being optional?) and ultimately vendors implement that is another
> discussion.

Sure. 

I do not have enough background with YANG models. Before having more opinions
avbout this, i would want to go investigate with yang experts what existing
models already have more intelligent options. E.g: anything i can use a
prior good practice to argue that the BIFT-ID mapping table could become
RO when i configure anothrer scheme - eg: esxisting IGP/MPLS automatic
label binding. When we figure out how the Yang model would best support
the current automatic MPLS label binding assignment, we should try to
use the same approach for native (together with this draft allocation
scheme).

> ok, let's not argue about the word "extension". I think we should discuss
> per the paragraph above WHAT is needed in Yang models in the most generic
> way possible to allow BIER users to use BIER with a "static provisioning"
> as Ice suggests which I think it a very good idea BTW.

Sure. Aka: BSL,SI,SD <=> BIFT-ID mapping i guess...
And a bunch more stuff if you completely want to eliminate the IGP.

> As reasoning: one of the reasons is I would want't to have something
> "special" for non-MPLS
> vs. MPLS would be to prevent something like IPv6 native encaps (or any
> other) coming in and saying: oh, look , we want yet another IF in the yang
> models or somewhere else, e'one is special ... Easier is short term, Not
> good for WG business in long term.

Sure. Given how my whole argument was trying to create as much parity
in the BIER framework between MPLS and non-MPLS when it comes to simplicity,
complete standards spec, etc. i'd certainly want to avoid one-offs for
either side. 

> > > What I see is that we'd have to expose in yang in every encapsulation the
> > > BIFT-id as something that can be written/provisioned. This is not only
> > good
> > > for static provisioning, this could be valuable for e.g. out-of-band
> > > controller signalling.
> >
> > Except that for MPLS and "bsl-sd-si", the bift <=> {BSL},SI,SD mapping
> > is read-only and for eg: non-mpls,flat it is rw, and you MUST write values
> > for this mapping consistently across all BSR. Probably also need to first
> > create the BIFTs via YANG.
> >
> > I may be wrong, Ice might have a different idea how to map his
> > "auto" cli to the yang model. In what i wrote above, it would be
> > via the "bsl-sd-si" assignment scheme parameter.
> >
> 
> yes, I read you. My opinion (technical and as individual here always) is
> that
> it's a good idea to have "static" provisioning easily doable with BIER and
> it's
> a practically understandable desire to have an *informational* suggestion
> how
> to do one such encoding by "default" and that way we could clearly
> emphasize that something that
> supports just such single encoding and nothing else is not "fully BIER
> standards conform" ...

sure, but this option does not create an equivalent to the current
MPLS-BIER "most-simple,fully-automatic,fully-standards" - unless we make this
bsl-si-sd mechanism also standard.

> > If there is even two possible and potentially manual configured schemes
> > for BIFT <=> SDL,SI,SD mapping, and there is inconsistent config,
> > then this creates huge package leaking security issues. Like L3VPN
> > packets ending up in wrong VPNs.
> >
> 
> yes, and that's what you get it you configure things statically. I don't
> think we should
> build new dynamic signalling to discover badly set manual overrides while
> we have a working
> dynamic signalling already that avoids that.

But we do not have a dynamic signaling to automatically discover thre
BIFT-ID to use towards the next-hop with native-IP forwarding. And
we can not even use the same approach in native (swap the BIFT-ID hop-by-hop..).

> One of the things folks forget easily is that when
> you take off the safety belts the freedom coming with it implies
> responsibility ... Tortuous path and I think the promised
> "simplicity" of the solution will quickly evaporate then.  I'm not saying
> it couldn't be done
> but I would argue it should not be done as part of "standards" BIER.
> <chair>If that didn't sink
> in "standards" track puts us on a much higher bar of thinking what the
> impact of all
> the stuff we're doing is and will be, there is all the work to come in the
> future and going on today
> that will have to start to answer to "HOW will that work with BIER?". That
> puts quite some
>  responsibility on us from now on. </chair>

True, but that makes it even more confusing to me why we do not try to
find a fully-standardized,most-simple-to-configure native-IP encap
option equivalent to the MPLS encap. This draft is the only bit missing
for that option.

All the explicit BIFT-ID config options is great for SDN fans
and i am happy to support via Yang too, but would never be my first worry.

> > Of course, this problem could equally be solved with IGP extensions,
> > ability to reduce the risk for this in the forwarding plane.
> >
> > > Generally true for attempts to push
> > > control plane functionality into data plane ...
> >
> > Like replacing perfectly fine control plane signalled multicast trees with
> > destination bits in packets ? ;-P
> 
> and mildly touche ;-) You're nasty but in a nice way ;-)  yeah, we're doing
> it, don't we ;-)

And proud for it ;-)

Don't keep up the draft from being accepted by WG on my behalf, i'll
just continue pounding on my opinion that i want a fully standardized
IP BIER stack equally simple to configure to what we have in MPLS.

And given how BIER RFCs are targeted to be upgraded from exp to std,
there is hope even laer in the life of this draft to have WG reconsider
its target.

Cheers
    Toerless