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

[Toerless Eckert <[e-mail]>]

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]