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

[Tony Przygienda <[e-mail]>]

Comments inline ...

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.

Further observations as individual.

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

> I am uncertain how useful the outcome of this work is as long as
> its "informational", "local decision..."
>
> I found Ice's explanation about the goals to Eric very useful.
>
> If we would scope the work to include the following 3 points i
> would give it a very enthusiastic approve as WG item:
>
> (1)Goal (described in doc): BIFT-ID Encoding to minimixe provisioning
> complexity:
>    Make non-MPLS option as easy (or easier) than MPLS encap: Avoid
>    to configure BIFT-ID <-> {SD,SI} mappings for every BIFT on every node
>    (or introduce new IGP signaling to auto-negotiate it).
>

Provisioning simplicity always a plus.


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


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


>
> I may be persuaded that there is enough value of not standardizing it (2),
> not documenting how to use it (1) or not making it supported via the YANG
> model (3). I would just like to understand why we would like to cripple
> the work so much. Without it, the non-MPLS encap will not catch up with
> MPLS. Is that the goal of the WG ?
>
> Technically, two points:
>
> 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. 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


> 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 and again, "static BIFT-id assignment" does not seem an
encapsulation to me ... Moreover, sinking signalling for that into OAM data
plane seems like a rather poor idea. Generally true for attempts to push
control plane functionality into data plane ...

--- tony