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

[Tony Przygienda <[e-mail]>]

On Tue, Mar 6, 2018 at 4:08 PM, Toerless Eckert <[e-mail]> wrote:

> Thanks, Tony
>

toerless,


>
> On Tue, Mar 06, 2018 at 02:29:07PM -0800, Tony Przygienda wrote:
> > As first: we do not have that in the charter currently as work item so I
> > suggest to poke the AD to expand it. Charters have wiggle room but this
> > seems stretching it unless AD signs off here as this being "Manageability
> > and OAM". And yes, we had adoption in the room & this thread generated
> good
> > amount of discussion, many in favor.
>
> Sure, and i was infavour of it as well, until i did a bit more
> due diligence and getting frustrated how this seems to be crippled
> with the way the work is currently scoped (informationally,...).
> Whats the reason to not try to get a standards solution for non-PLS
> thats as easy operationally as the MPLS solution ? This discussion
> is IMHO about the missing bits to achieve that.
>

ADs move in mysterious ways ;-)


>
> I am not sure about your interpretation of the charter issue.
> Maybe we first finish the technical arguments and then circle back  to ADs
> ?
>

yes, agreed ...


>
> > > (2) Target: IMHO should be same standards track as 8296. Probably
> update
> > >     RFC8296.
> >
> > While I could agree that it would be good to have a static provisioning
> > possibility I would disagree to make _a_ specific single
> > BIFT-assignment-scheme a standard.
>
> Why not ? We have a complete standard MPLS stack with no unnecessary
> manual bift config or undefined bits. Why can we not at least have one
> standard
> option for the same goal for non-MPLS ?
>
> I am not saying that we need to constrain the non-mpls side to ONLY
> ONE standard. There can be non-standard assignment schemes and/or
> even multiple standard assignment schemes in the future. All i want is
> at least one standard method to make selling & deployment of non-MPLS as
> easy and comparable to MPLS.
>

ok, reads clearer. I think I just got confused whether you're advocating a
new
encaps (which it all started to sound very much like to my ear)
or _all_ non-MPLS encaps to do that. If we say not a new encaps then
ok, discussion is somewhat more contained for me. ...


>
> > > (3) Draft should become normative reference to
> draft-ietf-bier-bier-yang.
> > >    To support this draft, YANG model just needs to introduce
> > >    encap option "bier-encap-bsl-sd-si" (some name). Nothing more
> needed!
> >
> > Are we confused here? This is _not_ an encapsulation, this is a BIFT-id
> > assignment scheme. You could achieve all that by not running any IGP (or
> > other signallling) and just assign static MPLS label values on MPLS
> > encoding so strictly speaking no new yang is necessary here IMO if I'm
> not
> > mistaken.
>
> Not sure if/how to correctly express this in YANG:
>
>   encapsulation type: { mpls, non-mpls}
>     bift-id-assignment-scheme: { label, bsl-sd-si, flat }
>       if encapsulation-type == mpls:
>          bift-id-assignment-scheme must be "label", read-only
>       if encapsulation type == non-mpls
>          bift-assignment-scheme: must NOT be label
>

 OK, and here I don't think anything like this is the best solution. What
is best solution IMO is saying

"every encaps needs a BIFT-id YANG element which is writeable" and yes, I
mean MPLS as well. I can
very well imagine peiople running MPLS encaps without IGP signalling but
setting
fixed values.  Known by cool names like SRGB and stuff ;-)  As side note: I
also think that
BIFT elements should be supported as optionally Yang writable so people can
download
full off-line computed BIFTs if they choose.  Whether we have to make it a
SHOULD or a
MUST (well, that's difficult in models, probably best expressed by whole
BIFT Yang
branch being optional?) and ultimately vendors implement that is another
discussion.


> > > a) However this work proceeds, we would need to add parameters to the
> > >    YANG draft to support the "arbitrary" BIFT-ID assignment. I think
> > >    this would mean some "flat-bift-id" encapsulation type and a
> > >    list of per (SD,SI) BIFT-ID parameters in the appropriate place
> > >    of the YANG data model. Make this mandatory to support.
> > >
> > >    The mandatory need to support those flat BIFT-ID encoding parameters
> > >    is my best idea how to ensure Erics concern does not happen:
> platforms
> > >    that will not allow you do use any BIFT-ID.
> > >
> > Again, I don't see any extensions needed since this is not an encaps.
>
> Extension of the yang data model.
>

ok, let's not argue about the word "extension". I think we should discuss
per the paragraph above WHAT is needed in Yang models in the most generic
way possible to allow BIER users to use BIER with a "static provisioning"
as Ice
suggests which I think it a very good idea BTW.

As reasoning: one of the reasons is I would want't to have something
"special" for non-MPLS
vs. MPLS would be to prevent something like IPv6 native encaps (or any
other) coming in and saying: oh, look , we want yet another IF in the yang
models or somewhere else, e'one is special ... Easier is short term, Not
good for WG business in long term.


>
> > What I see is that we'd have to expose in yang in every encapsulation the
> > BIFT-id as something that can be written/provisioned. This is not only
> good
> > for static provisioning, this could be valuable for e.g. out-of-band
> > controller signalling.
>
> Except that for MPLS and "bsl-sd-si", the bift <=> {BSL},SI,SD mapping
> is read-only and for eg: non-mpls,flat it is rw, and you MUST write values
> for this mapping consistently across all BSR. Probably also need to first
> create the BIFTs via YANG.
>
> I may be wrong, Ice might have a different idea how to map his
> "auto" cli to the yang model. In what i wrote above, it would be
> via the "bsl-sd-si" assignment scheme parameter.
>

yes, I read you. My opinion (technical and as individual here always) is
that
it's a good idea to have "static" provisioning easily doable with BIER and
it's
a practically understandable desire to have an *informational* suggestion
how
to do one such encoding by "default" and that way we could clearly
emphasize that something that
supports just such single encoding and nothing else is not "fully BIER
standards conform" ...


>
> > > b) I think it would be great if we had inband recognition of
> misconfigured
> > >    BIFT-IDs without the need to depend on the control plane.
> > >
> > >    Given how the BSL aready has a header field, it seems we would not
> > >    need it in the BIFT-ID, but could use (some of) those bits to
> identify
> > > the
> > >    encoding, and make this mechanism be one encoding value.
> > >
> > >
> > We could start to 'grab bits' in the BIFT-id to identify something but we
> > don't have any,  encodings like MPLS took all 20 bits
> > and hence we don't have space
>
> For MPLS BIER packets, there is only one permitted encoding of the BIFT-ID
> field, and thats standardized. So no need to check for misconfiguration
> between
> sending and receiving BFR. We only need such a check when there are
> different
> methods used, and in non-MPLS BIER, that would be the case.
>
> > and again, "static BIFT-id assignment" does not seem an encapsulation to
> me
>
> Is this a charter scope or a technical point ?
> If technical please rephrase, didn't understand.
>

I think it cleared above ... All technical unless I tag otherwise. my very
first paragraph in the previous
email was charter scope, I have the sometimes unpleasant job to point out
the
playing field ...


>
> > ... Moreover, sinking signalling for that into OAM data
> > plane seems like a rather poor idea.
>
> If there is even two possible and potentially manual configured schemes
> for BIFT <=> SDL,SI,SD mapping, and there is inconsistent config,
> then this creates huge package leaking security issues. Like L3VPN
> packets ending up in wrong VPNs.
>

yes, and that's what you get it you configure things statically. I don't
think we should
build new dynamic signalling to discover badly set manual overrides while
we have a working
dynamic signalling already that avoids that. One of the things folks forget
easily is that when
you take off the safety belts the freedom coming with it implies
responsibility ... Tortuous path and I think the promised
"simplicity" of the solution will quickly evaporate then.  I'm not saying
it couldn't be done
but I would argue it should not be done as part of "standards" BIER.
<chair>If that didn't sink
in "standards" track puts us on a much higher bar of thinking what the
impact of all
the stuff we're doing is and will be, there is all the work to come in the
future and going on today
that will have to start to answer to "HOW will that work with BIER?". That
puts quite some
 responsibility on us from now on. </chair>


>
> The draft proposal if consistently configured throughput the network does
> (like MPLS encap) not have this issue. Therefore we really only need to
> recognize whether a non-mpls packets bift-id uses this assignment scheme
> or not. With that check, the non-MPLS solution wold have the same
> automatic-assinment based prortection against mismatches of
> bift-assignments
> as the MPLS solution.
>
> I think cross-VPN package leakage is a typical security issue you would
> like
> to NOT leave to offline configuration methods, but rather ensure it
> happens inside the solution. In the absence of the IGP signaling used by
> MPLS, these bits in the bift-id itself are the easiest way to achieve
> this.
>

yes, I agree with the fact that VPN cross-leakage is a no-go. It put a
serious crimp into L3VPN discussions in its time until it was clarified in
standards and products AFAIR ;-)


>
> Of course, this problem could equally be solved with IGP extensions,
> ability to reduce the risk for this in the forwarding plane.
>
> > Generally true for attempts to push
> > control plane functionality into data plane ...
>
> Like replacing perfectly fine control plane signalled multicast trees with
> destination bits in packets ? ;-P
>

and mildly touche ;-) You're nasty but in a nice way ;-)  yeah, we're doing
it, don't we ;-)

--- tony

>
>