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

[Toerless Eckert <[e-mail]>]

Thanks, Tony

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.

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

> > (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.

> > (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
  
> > 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.

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

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

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

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.

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 

Cheers
    toerless

> 
> --- tony