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

[Tony Przygienda <[e-mail]>]

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