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

[Toerless Eckert <[e-mail]>]

Will inhale your mail over longer period ;-)

The idea of BCCT was just in reminder that we typically have three
layers - (protocol) topology table, routing table, forwarding table.

In the absence of controller there is IMHO not a lot of difference
between BIRT and BIFT - certainly a lot less than in RIB/FIB or MRIB/MFIB.
So with controller thrown in, what would look like a nice local mapping
of what we want to do to our pre-existing three tier architecture. 
Thats all. Just the question. No answer yet.

My BIER-TE teas draft also proposes some use of the terminology. Similarily
no conclusion yet.

Cheers
    Toerless

On Fri, Mar 09, 2018 at 06:00:22PM -0800, Tony Przygienda wrote:
> Toerless, all agreed, worth talking it through and see what emerges. I
> don't think we need a new concept like BCCT (or maybe we do) and I think
> that we should think whether writing just BIRTs (including next-hops) is
> good enough. Maybe it is and we don't even have to write BIFTs but in case
> of TE I think we need writable BIFTs as well (but here I would encourage a
> split in Yang given that TE really interprets the mask very, very
> differently) ... So BIFT-id is just a side-show if the group thinks it's a
> good direction to go and work on.
> 
> (I never "want it" ;-) but based on other people's long experience I
> learned from) in control plane I always strive for the "widest
> architecture" which you can call flexible unless complexity or performance
> becomes unmanageable. Complexity is structured by keeping things orthogonal
> (i.e. exceptions and interactions between things @ minimum), things like
> having some special back-off on BIFT-id in one encaps or overlapping pieces
> can hog-tie the architecture up over time due to all the exceptions
> created. So yes, IMO it's worth hard thinking how to generalize/keep things
> clean, it's just brain cycles over beer and dinners comparatively speaking
> ...  Control plane today performance wise is cheap if done correctly in my
> daily experience but yes, there are limits. And otherwise RFC1925 12)
> always applies.
> 
> In the forwarding path it's the opposite, least amount of abstractions,
> very tight encodings,  minimal flexibility, least structure that is
> feasible. It's silicon gates and beside power/size/gates the more complex
> the fwd' path the buggier the chips and the longer it takes to get anything
> working in the field.
> 
> And again, we're in STD track, it's a higher standard we will/should be
> held up to so the thinking and possibly iteration of different ideas may
> tend to take more time. We got the first rush of delivering a good base out
> there & deployments have enough to catch up, we have the time I think to do
> things we focus now on thoughtfully and well ...
> 
> --- tony
> 
> On Fri, Mar 9, 2018 at 4:50 PM, Toerless Eckert <[e-mail]> wrote:
> 
> > Ok. you want the most fine/grained/flexible option...
> >
> > [Ignoring defaults semantics in Yang, no idea yet what that means.]
> >
> > We create writeable BCTT (Bier Controller Topology Table) with bit entries
> > like BIRT, each has a preference value. We have a read-only BIRT where we
> > will see
> > for each bit either the bit semantic from the BCTT if the controller won,
> > or the IGP
> > learned bit info when the IGP won.  Not sure if/how we would assign
> > preference
> > to IGP entries. COUld be confgiured default, could be inherited from
> > existing IGP Yang model preferences. Not even sure if IGP Yang models
> > include
> > preference semantic. If theey do we should try to figure out how we can
> > best be compatible.
> >
> > Of course lot more refinemenet needed. Would be good if everything we do
> > could be
> > declared to be stolen 1:1 from existing yang/igp best practices and
> > adopted by considering bfr-id's to be just another address/prefix type.
> >
> > Cheers
> >     Toerless
> >
> > On Fri, Mar 09, 2018 at 09:48:54AM -0800, Tony Przygienda wrote:
> > > Toerless, thanks, good observation.
> > >
> > > My preference would be with a "like route-preference" based approach to
> > > avoid configuring things per SD, per node but it would be interesting to
> > > hear other opinions.  And the static (just like static route) always
> > beats
> > > dynamic normally, worked extremely well in IP routing case ...
> > >
> > > Yes, I forgot that in BIER-TE case that may be extremely useful as well
> > ...
> > >
> > > --- tony
> > >
> > > On Fri, Mar 9, 2018 at 8:58 AM, Toerless Eckert <[e-mail]> wrote:
> > >
> > > > Well, if you want to experiment with defining a full BIFT in yang,
> > > > we'd need that IMHO more with BIER-TE than BIER first because that one
> > > > relies ground up on a controller, and i first need LSR work for
> > > > the IGP extensions to create an 'reduced controller dependent' option.
> > > >
> > > > For BIER, the most difficult question to answer unfortunately first
> > > > is probably the way how to deal with conflicts between controller
> > > > and IGP generation of BIFT entries.
> > > >
> > > > If its sufficient, then we could make this based on some per-domain
> > > > or per-sd or per-bift mode-switch.
> > > >
> > > > Or its even based on per-bift-entry (bit) preference: Both IGP
> > > > and controller can write info, but it will have different precedence,
> > > > and the BIFT will carry highest precedence info (like we do it
> > > > for routes in RIBs/FIBs).
> > > >
> > > > I would suggest to go with per-sd mode switch, that allows
> > > > co-extance of controller for some sd and igp for others and keeps
> > > > it simple. But no strong opinion because i have not concrete
> > > > idea of the most important BIER + controller use case to model
> > > > the details.
> > > >
> > > > Cheers
> > > >     Toerless
> > > >
> > > >
> > > > On Thu, Mar 08, 2018 at 05:07:52PM -0800, Tony Przygienda wrote:
> > > > > Yes, Sandy, that's what I personally think would be a very good
> > property
> > > > of
> > > > > BIER yang model but AFAIS we don't even have BIFT-id in the model
> > right
> > > > > now. Maybe we should talk in London face 2 face a bit so you can
> > tell me
> > > > > what you think. Toerless may join ;-)  Obviously it's quite an
> > addition,
> > > > > we'd need to expose BIFTs in the config part and not now as some
> > > > > BIRT-sub-thingy-in-state-branch ...  I would even go further and
> > think
> > > > > whether we want to expose BIFT entries as writable entries to make
> > > > support
> > > > > for controller based/unsignalled solutions trivial (because
> > otherwise,
> > > > what
> > > > > good is it to just have a BIFT-id mapping if there is no IGP to
> > compute
> > > > the
> > > > > BIFTs actually. And if we have IGP running then part of the
> > configuration
> > > > > could be something like a "static mapping algorithm ID" anyway  ;-) ?
> > > > >
> > > > > --- tony
> > > > >
> > > > > On Thu, Mar 8, 2018 at 4:45 PM, <[e-mail]> wrote:
> > > > >
> > > > > > Hi Tony, hi Toerless,
> > > > > >
> > > > > >
> > > > > > Sorry for the late response. I read the latest emails but I have
> > not
> > > > > > finished the whole thread (It is so long. :P)
> > > > > >
> > > > > > Do you discuss the flexibity of BIFT-id?
> > > > > >
> > > > > > If it is, we would like to add a readable and writable leafs in the
> > > > YANG
> > > > > > model. Is it enough?
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Sandy
> > > > > >
> > > > > >
> > > > > > ????????????
> > > > > > *????????????*TonyPrzygienda <[e-mail]>
> > > > > > *????????????*Toerless Eckert <[e-mail]>
> > > > > > *????????????*Greg Shepherd <[e-mail]>BIER WG <
> > [e-mail]>
> > > > > > *??? ??? ???*2018???03???08??? 09:55
> > > > > > *??? ??? ???**Re: [Bier] Call for
> > > > > > adoption:draft-wijnandsxu-bier-non-mpls-bift-encoding-01*
> > > > > > _______________________________________________
> > > > > > BIER mailing list
> > > > > > [e-mail]
> > > > > > https://www.ietf.org/mailman/listinfo/bier
> > > > > >
> > > > > > IMO having a writable BIFT-id field for all encaps in the yang
> > models
> > > > is
> > > > > > all we need and would be good to have in first release while all
> > the
> > > > > > encoding discussion can continue ... But I forgot all about the
> > yang
> > > > draft
> > > > > > since I looked @ it last time :^)
> > > > > >
> > > > > > -- tony
> > > > > >
> > > > > > On Wed, Mar 7, 2018 at 5:47 PM, Toerless Eckert <[e-mail]>
> > wrote:
> > > > > >
> > > > > >> Sure & thanks
> > > > > >>
> > > > > >> Hope we have some time over a beer for me to understand your
> > > > resistance
> > > > > >> to the standard mapping, i think we won't make progress on this in
> > > > email.
> > > > > >>
> > > > > >> Hope the Yang draft authors listened here on the thread, but
> > maybe if
> > > > > >> we don't see an ack from one of them to this email, i'll resend an
> > > > > >> explicit
> > > > > >> ask to start brainstorming for the yang modelling of <bsl,si,sd>
> > <->
> > > > bift
> > > > > >> mapping ? Or do you think this should go into a followup
> > document  and
> > > > > >> not the existing yang drafgt ?
> > > > > >>
> > > > > >> Cheers
> > > > > >>     Toerless
> > > > > >>
> > > > > >>
> > > > > >> On Wed, Mar 07, 2018 at 03:48:17PM -0800, Tony Przygienda wrote:
> > > > > >> > OK, I voiced my opinion and stop here and wait now whether we're
> > > > > >> calling a
> > > > > >> > standards track here and what the scope of the ask is precisely
> > now
> > > > > >> >
> > > > > >> > a) having writable Yang BIFT-ids  (I'm for)
> > > > > >> > b) having an informational mapping for network-wide BIFT-id on
> > > > non-MPLS
> > > > > >> > encaps (I'm neutral)
> > > > > >> > c) having standard mapping for network-wide BIFT-id on non-MPLS
> > > > encaps
> > > > > >> (I'm
> > > > > >> > against)
> > > > > >> > d) draft adoption as it stands as informational (I'm neutral)
> > > > > >> >
> > > > > >> > fair 'nuff?
> > > > > >> >
> > > > > >> > -- tony
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > On Wed, Mar 7, 2018 at 2:08 PM, Toerless Eckert <[e-mail]>
> > > > wrote:
> > > > > >> >
> > > > > >> > > On Tue, Mar 06, 2018 at 08:03:06PM -0800, Tony Przygienda
> > wrote:
> > > > > >> > > > agreed except the mapping cannot be standardized IMO ...
> > This is
> > > > > >> like
> > > > > >> > > > telling people which IP addresses to run their DNS servers
> > on
> > > > ...
> > > > > >> > >
> > > > > >> > > That i think the fallacy. If we simply had fixed, standard
> > defined
> > > > > >> > > fields separately for BSL, SI, SD, we would not have any of
> > this
> > > > > >> > > discussion.
> > > > > >> > >
> > > > > >> > > The whole issue stems from the fact of how we're
> > interpreting  the
> > > > > >> > > semantic of the BIFT-ID field.
> > > > > >> > >
> > > > > >> > > The most easy way to bring this confusing discussion back to
> > > > > >> established
> > > > > >> > > practices would something like: The first 4 bits define what
> > the
> > > > > >> > > remaining 16 bits mean. IANA registry, we define 2
> > assignments.
> > > > > >> > > In one assignment, the following 16 bits are SI, SD (BSL
> > already
> > > > > >> exists
> > > > > >> > > in another part of the header). In another assigned value it
> > > > means the
> > > > > >> > > remaining 16 bits are assigned by undefined procedures (eg:
> > SDN
> > > > > >> > > controller).
> > > > > >> > >
> > > > > >> > > We could strip down the "selection" to even just 1 bit. 2
> > bits to
> > > > be
> > > > > >> > > safe for someone coming up with a 3rd good idea.
> > > > > >> > >
> > > > > >> > > If you want to be able to reuse all 20 bits with botentially
> > > > > >> inconsistent
> > > > > >> > > semantic than you're getting yourself into this interpretation
> > > > issue.
> > > > > >> But
> > > > > >> > > it still is only network wide one-bit of consistent
> > configuration
> > > > > >> required:
> > > > > >> > > all nodes need to aggree to use this bsl-si-sd assignment
> > scheme.
> > > > Its
> > > > > >> > > the second best solution IMHO, and it would be a lot stronger
> > if
> > > > it
> > > > > >> was
> > > > > >> > > standardized and recommended than if it was just an
> > informational
> > > > > >> > > suggestion.
> > > > > >> > >
> > > > > >> > > Btw: We could do even more nasty encoding tricks:
> > > > > >> > > We could say that the BIFT-ID field uses the bsl-si-sd format
> > if
> > > > > >> > > the existing BSL field is 0. That way we would have the full
> > 20
> > > > bit
> > > > > >> > > to indicate the "standardized" bsl-si-sd and can still have
> > the
> > > > full
> > > > > >> > > 20 bits for any non-standardised mechanisms.
> > > > > >> > >
> > > > > >> > > > > 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 ;-)
> > > > > >> > >
> > > > > >> > > Why are you not making the same argument about the TTL field
> > ? Or
> > > > > >> > > DSCP field or any other fields in a header where we
> > standardise a
> > > > > >> network
> > > > > >> > > wide
> > > > > >> > > consistent semantic ?
> > > > > >> > >
> > > > > >> > > IMHO its exactly the other way around: The most reliably
> > working
> > > > > >> > > interoperable
> > > > > >> > > solutions are those not depending on signaling, but purely on
> > > > > >> standardized
> > > > > >> > > network wide consistly interpreted inband signaling elements.
> > > > > >> > >
> > > > > >> > > Yes, the desire to have multiple interpretations of one field
> > is
> > > > > >> always an
> > > > > >> > > interesting challenge. The IETF tried to avoid this in the
> > past
> > > > most,
> > > > > >> > > primaily also because of inflexibilities of forwarding plane.
> > Seee
> > > > > >> above
> > > > > >> > > for some of my ideas how to mitigate the issue. "Preferred
> > > > standard
> > > > > >> > > semantic"
> > > > > >> > > is definitely part of the best working solution strategy.
> > > > > >> > >
> > > > > >> > > > 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
> > > > > >> > >
> > > > > >> > > How avbout those 4 bits in the IPv4 header indicating what
> > > > version of
> > > > > >> > > the packet it is...
> > > > > >> > >
> > > > > >> > > Its really just based on whether you want to make your and the
> > > > drafts
> > > > > >> life
> > > > > >> > > more miserable by coming up with the most convoluted
> > > > interpretation of
> > > > > >> > > flexibility - or not.
> > > > > >> > >
> > > > > >> > > > > 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 ;-)
> > > > > >> > >
> > > > > >> > > Don't start with the technical option. Motivate me with the
> > > > benefits
> > > > > >> first
> > > > > >> > > ;-)
> > > > > >> > >
> > > > > >> > > Eric also didn't answer my question wrt to other encap
> > > > > >> option/benefits.
> > > > > >> > > 9other than the generic "SDN-controller" which we discussed).
> > > > > >> > >
> > > > > >> > > > > 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"
> > > > > >> > >
> > > > > >> > > Ok. Don't understand why you're stopping there. To me it just
> > > > means to
> > > > > >>
> > > > > >> > > end up with a solution thats not as simple as the MPLS
> > solution
> > > > and
> > > > > >> > > with making the encoding standard it would become as simple
> > (and
> > > > would
> > > > > >> > > still
> > > > > >> > > allow for other options).
> > > > > >> > >
> > > > > >> > > > 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.
> > > > > >> > >
> > > > > >> > > Sure. But we do not need a label in non-MPLS forwarding. We
> > just
> > > > need
> > > > > >> to
> > > > > >> > > know SI,SD.
> > > > > >> > > (already have HSL).
> > > > > >> > >
> > > > > >> > > Which makes it somewhat frustrating... somehow i am missing
> > > > something
> > > > > >> > > very fundamental why this needs to be so much overthought.
> > > > > >> > >
> > > > > >> > > > > 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>
> > > > > >> > >
> > > > > >> > > Of course. Which is why i said i will abstain from a vote
> > right
> > > > now
> > > > > >> > > because i
> > > > > >> > > love the work, but i think without being standards track its
> > just
> > > > > >> > > introducing
> > > > > >> > > more confusion than benefit.
> > > > > >> > >
> > > > > >> > > Cheers
> > > > > >> > >     Toerless
> > > > > >> > > >
> > > > > >> > > > --- tony
> > > > > >> > >
> > > > > >> > > > _______________________________________________
> > > > > >> > > > BIER mailing list
> > > > > >> > > > [e-mail]
> > > > > >> > > > https://www.ietf.org/mailman/listinfo/bier
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > > ---
> > > > > >> > > [e-mail]
> > > > > >> > >
> > > > > >>
> > > > > >> --
> > > > > >> ---
> > > > > >> [e-mail]
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > ---
> > > > [e-mail]
> > > >
> >
> > --
> > ---
> > [e-mail]
> >

-- 
---
[e-mail]