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

[" 徐小虎(义先) " <[e-mail]>]

Hi Tony，
Please see my comments inline with [Xiaohu]
------------------------------------------------------------------Tony Przygienda <[e-mail]>2018年3月7日(星期三) 06:29Toerless Eckert <[e-mail]>Greg Shepherd <[e-mail]>; BIER WG <[e-mail]>Re: [Bier] Call for adoption: draft-wijnandsxu-bier-non-mpls-bift-encoding-01
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. 
[Xiaohu] I just reread the current charter and didn't find the thread where the non-MPLS BIER encapsulation is allowed while the BIFT encoding is prohibited:) IMHO, the BIFT encoding is a missing piece of the non-MPLS encapsulation. Otherwise, I don't know what's the meaning of specifying the non-MPLS encapsulation scheme given the fact that the MPLS-BIER encapsulation has been specified.
 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. 
 [Xiaohu] It's a very important missing part of the non-MPLS encapsulation, not just a BIFT-ID assignment scheme. If you still remember the history of the non-MPLS BIER encapsulation, the idea of embeding {BSL, SI, Sub-domain} in the BIER packet has never been changed from day one (for more details, see https://tools.ietf.org/html/draft-xu-bier-encapsulation).  Unfortunately, the concept of the non-MPLS BIER encapsulation was partially absorbed into the MPLS-BIER encapsulation draft (https://tools.ietf.org/wg/bier/draft-ietf-bier-mpls-encapsulation/) with the idea of embeding {BSL, SI, Sub-domain} directly in the BIER packet being missing. I always believe this missing part is the most valuable part of the non-MPLS BIER encapsulation. I had thought I should raise this question when the MPLS-BIER encapsulation draft was in the process of WGLC. However, when Ice proposed to describe the missing part in a separate draft (i.e., draft-wijnandsxu-bier-non-mpls-bift-encoding), I felt it was not a bad idea. I think it's not too late to fix this missing part since BIER is still in the Experimental status currently.
Best regards,Xiaohu

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