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

[Tony Przygienda <[e-mail]>]

On Tue, Mar 6, 2018 at 6:32 PM, Toerless Eckert <[e-mail]> wrote:

> 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.
>

ack, agreed


>
> 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.
>

agreed except the mapping cannot be standardized IMO ... This is like
telling people which IP addresses to run their DNS servers on ...


>
> > 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.
>
>
agreed


> > > > 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.
>

well, you try the impossible here. You can't have static provisioning being
as simple and worry-free as a dynamic signalling protocol, otherwise the
whole world would still route using static routes and no'one would bother
with the complexity of distributed algorithms, Toerless ;-)

IMO best you  can do is ensure that any BIFT-id can be provisioned and give
people some informational on how encoding is recommended. And build some
informational mechanism to discover "misconfiguration" but please, not as
part of standard track OAM


>
> > > 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..).
>


who said. What prevents you from using a "non-MPLS" label space and signal
that in ethernet encaps extensions in IGP (I smell a draft for people right
there ;-)  0x8847 has a point ;-)


>
> > 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.
>

so that's what the thread is all about. My take (and I'm one voice but Greg
builds consenus having called it) that I'm all dandy to make "BIFT-id MUST
be capable of being out-of-band provisioned on Yang" but I'll stop at
"here's one information, recommended encoding"


> > 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 ;-)
>

And please don't stop ;-) BIER is not built around singing kumbaya too
often ;-)


>
> 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.
>

I'm just one voice but I'll pound most likely with the charter if we try to
make the mapping algorithm a "standard" because from my experience,
exposing control plane elements to fast path ends up in tears. We may end
up with sub-sub-domain (yeah, I know, just an example) and then what will
you do with this "this is control-plane 1:1 mapping to fast-path",
especially if it's standard. We'll have a "broken" standard after stuff is
deployed. There is a very deep reason MPLS labels have no structure to
them.


>
> 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.
>
>
<chair> Consensus was called for informational, if you want to change the
scope to "standard" that's a very different kettle of fish & Greg has to
call a new adoption call IMSO. </chair>

--- tony