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

[Tony Przygienda <[e-mail]>]

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