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

[Toerless Eckert <[e-mail]>]

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]