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

[Toerless Eckert <[e-mail]>]

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]