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

[Tony Przygienda <[e-mail]>]

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