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

From: Toerless Eckert <[email-masked]>
Date: Tue, 6 Mar 2018 18:38:11 +0100

Ice, Eric, *:

Inline,

On Tue, Feb 27, 2018 at 06:59:47PM +0100, IJsbrand Wijnands wrote:
> router bier
>  encapsulation non-mpls bsl-sd-si bsl 256
                          ^^^^^^^^^
>   sub-domain 1
>    source loopback 0
>    bift-id auto
     ^^^^^^^^^^^^ probably redundant/default
>   !

Of course, cli is IETF contraband, but: 

Can we not try to overcome Erics concern by making sure the
BIER YANG data model has a mandatory way to provision bift-id's
both via "flat-bift" and "bsl-sd-si". Aka: the "flat-bift"
would the option that (the way i understand it) Eric is concerned
about. Likewise the auto part would be good to describe in the
YANG model (i assume that you somehow try to figure out the max
SI needed, but not quite sure how).

I have always been a fan of first working out the operator
interface and dedude from that the required protocol details.
Not the other way around. Before YANG we're almost not even

allowed to talk about this idea (operator interface not standardized,
go away). With YANG now it seems we do have the chance to also
start doing this in the IETF.

Cheers
    Toerless

>  !
> !
> 
> I would think that such configuration is the minimum required on every BIER router (unless there are default that don???t need to be required) independent of the vendor.
> 
> Based on the above we can generate a BIFT-id following the draft proposal. Two different vendors having BIER configured will be interoperable because they generate the same BIFT-id, without having to configure it.
> 
> It is also possible to configure:
> 
> router bier
>  encapsulation non-mpls bsl 256
>   sub-domain 1
>    source loopback 0
>    bift-id 10000
>   !
>  !
> !
> 
> Now the operator needs to manage value ???10000??? and make sure its configure on every router the same.
> 
> Thx,
> 
> Ice.
> 
> 
> > On 27 Feb 2018, at 18:46, Eric C Rosen <[email-masked]> wrote:
> > 
> > On 2/27/2018 12:25 PM, IJsbrand Wijnands wrote:
> >> If we want to be interoperable among different vendors, I think it is good to have this documented.
> > 
> > This is the sort of statement that really worries me.  What is the interoperability issue?  As long as a vendor allows the assignment of BIFT-ids, interoperability should be possible without the need for any particular suggested way of constructing the BIFT-ids.
> > 
> > I'm not sure we can say both that the draft is informational, and that it is needed for multi-vendor interoperability.
> > 
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 6 Mar 2018 18:43:38 +0100

Eric, *

Q1: Is there any text you could point me to that would give
me an idea how a non bsl-sd-si encoding of the bift-id would
be beneficial (non-mpls of course) ?

Q2: What would be the harm of deploying software (non-mpls)
that would only support this bift-id encoding ? Specific example
welcome.

Thanks
    Toerless

On Tue, Feb 27, 2018 at 09:58:45AM -0500, Eric C Rosen wrote:
> I am strongly opposed to the adoption of this draft.
> 
> The premise of the draft is that in non-MPLS networks, operators may
> want to assign a domain-wide unique BIFT-id that denotes, in every
> BFR, the BIFT associated with a given <SD,SI,BSL> triple.
> 
> That may be true.  However, there are many procedures that can be
> used to assign domain-wide unique BIFT-ids.  There is no reason for
> the WG to give the appearance of endorsing any one procedure over
> any of the thousands of others.  This is really a decision for the
> network operators.  So I think the document is not very useful.
> 
> I do however think the document is harmful.  It will inevitably
> result in the deployment of software (if not hardware) that cannot
> process non-MPLS BIER packets in which the BIFT-id is not formed
> according to the rules of this draft.
> 
> Yes, yes, the draft says that the use of this encoding is OPTIONAL,
> and the draft is merely Informational.  That won't help us much when
> some implementation (either from a vendor, or open source) gets
> deployed that requires the use of this encoding.
> 
> Drafts that are harmful but not useful should not be adopted by the WG.
> 
> If this draft proceeds, I suggest it be turned into an Independent
> Submission, so that it can be made clear that the draft just
> describes a suggestion by the authors.
> 
> 
> 
> 
> 
> On 2/26/2018 1:07 PM, Greg Shepherd wrote:
> >In Singapore we had solid support to
> >adopt draft-wijnandsxu-bier-non-mpls-bift-encoding as a WG draft.
> >
> >This is a call to the list for adoption. Please read and reply
> >with/without support to this thread:
> >
> >https://datatracker.ietf.org/doc/draft-wijnandsxu-bier-non-mpls-bift-encoding/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwijnandsxu-2Dbier-2Dnon-2Dmpls-2Dbift-2Dencoding_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=l-KKk7BthqSx7OjcMbxS5nkQZLR40fjA3UQvFQzbEas&s=jcUd-KEqRjNnt4plMdrqae2oeOhQSHIV_oZGcxtxnrg&e=>
> >
> >Thanks,
> >Greg
> >
> >
> >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=l-KKk7BthqSx7OjcMbxS5nkQZLR40fjA3UQvFQzbEas&s=AjVaQdEtidRkJYHuMaOE3AynPR5gmY4zjT7WulICH1Q&e=
> 

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 6 Mar 2018 22:45:58 +0100

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

(2) Target: IMHO should be same standards track as 8296. Probably update
    RFC8296.

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

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.

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.

Cheers
    Toerless

On Mon, Feb 26, 2018 at 10:07:05AM -0800, Greg Shepherd wrote:
> This is a call to the list for adoption. Please read and reply with/without
> support to this thread:
> 
> https://datatracker.ietf.org/doc/draft-wijnandsxu-bier-non-mpls-bift-encoding/
> 
> Thanks,
> Greg

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 6 Mar 2018 14:29:07 -0800

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.

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

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.

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

>    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

>    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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Mar 2018 01:08:21 +0100

Thanks, Tony

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

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

> encoding so strictly speaking no new yang is necessary here IMO if I'm not

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

> 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

Like replacing perfectly fine control plane signalled multicast trees with
destination bits in packets ? ;-P 

Cheers
    toerless

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 6 Mar 2018 17:13:15 -0800

> Thanks, Tony

toerless,

> is IMHO about the missing bits to achieve that.

ADs move in mysterious ways ;-)

> Maybe we first finish the technical arguments and then circle back  to ADs

yes, agreed ...

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

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

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

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

> > >    need it in the BIFT-ID, but could use (some of) those bits to
> identify
> > > the

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

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

> MPLS, these bits in the bift-id itself are the easiest way to achieve

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 ;-)

> 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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Mar 2018 03:32:38 +0100

> branch being optional?) and ultimately vendors implement that is another

Sure. 

I do not have enough background with YANG models. Before having more opinions
avbout this, i would want to go investigate with yang experts what existing
models already have more intelligent options. E.g: anything i can use a
prior good practice to argue that the BIFT-ID mapping table could become
RO when i configure anothrer scheme - eg: esxisting IGP/MPLS automatic
label binding. When we figure out how the Yang model would best support
the current automatic MPLS label binding assignment, we should try to
use the same approach for native (together with this draft allocation
scheme).

> as Ice suggests which I think it a very good idea BTW.

Sure. Aka: BSL,SI,SD <=> BIFT-ID mapping i guess...
And a bunch more stuff if you completely want to eliminate the IGP.

> good for WG business in long term.

Sure. Given how my whole argument was trying to create as much parity
in the BIER framework between MPLS and non-MPLS when it comes to simplicity,
complete standards spec, etc. i'd certainly want to avoid one-offs for
either side. 

> supports just such single encoding and nothing else is not "fully BIER

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.

> dynamic signalling already that avoids that.

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

> One of the things folks forget easily is that when

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.

All the explicit BIFT-ID config options is great for SDN fans
and i am happy to support via Yang too, but would never be my first worry.

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

And proud for it ;-)

Don't keep up the draft from being accepted by WG on my behalf, i'll
just continue pounding on my opinion that i want a fully standardized
IP BIER stack equally simple to configure to what we have in MPLS.

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.

Cheers
    Toerless

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 07 Mar 2018 11:37:05 +0800

Hi Tony，
Please see my comments inline with [Xiaohu]
------------------------------------------------------------------Tony Przygienda <[email-masked]>2018年3月7日(星期三) 06:29Toerless Eckert <[email-masked]>Greg Shepherd <[email-masked]>; BIER WG <[email-masked]>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. 

    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. 

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

Technically, two points:

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 

 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

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 6 Mar 2018 20:03:06 -0800

> > branch being optional?) and ultimately vendors implement that is another

ack, agreed

> And a bunch more stuff if you completely want to eliminate the IGP.

agreed except the mapping cannot be standardized IMO ... This is like
telling people which IP addresses to run their DNS servers on ...

> complete standards spec, etc. i'd certainly want to avoid one-offs for
agreed

> > > > BIFT-id as something that can be written/provisioned. This is not
> only
> > > good

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 ;-)

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

> we can not even use the same approach in native (swap the BIFT-ID

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 ;-)

> option equivalent to the MPLS encap. This draft is the only bit missing

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"

> > and mildly touche ;-) You're nasty but in a nice way ;-)  yeah, we're

And please don't stop ;-) BIER is not built around singing kumbaya too
often ;-)

> IP BIER stack equally simple to configure to what we have in MPLS.

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.

> there is hope even laer in the life of this draft to have WG reconsider
<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>

--- tony

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Mar 2018 23:08:30 +0100

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

> > MPLS-BIER "most-simple,fully-automatic,fully-standards" - unless we make
> > this bsl-si-sd mechanism also standard.
> >
> 

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.

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

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

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

> deployed. There is a very deep reason MPLS labels have no structure to

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.

> 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

-- 
---
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 7 Mar 2018 15:48:17 -0800

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 8 Mar 2018 02:47:34 +0100

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

-- 
---
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 7 Mar 2018 17:54:26 -0800

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 <[email-masked]> wrote:

> > > > > MPLS-BIER "most-simple,fully-automatic,fully-standards" - unless
> we
> > > make
> > > DSCP field or any other fields in a header where we standardise a
> network
> > > wide
> > > consistent semantic ?
> > >
> > > > IMO best you  can do is ensure that any BIFT-id can be provisioned
> and
> > > give
> > > Don't start with the technical option. Motivate me with the benefits
> first
> > > ;-)
> > >
> > > > so that's what the thread is all about. My take (and I'm one voice
> but
> > > Greg
> > > > I'm just one voice but I'll pound most likely with the charter if we
> try
> > > to
> > > > especially if it's standard. We'll have a "broken" standard after
> stuff
> > > is
> > > Sure. But we do not need a label in non-MPLS forwarding. We just need
> to
> > > know SI,SD.
> > > (already have HSL).
> > >

---

From: <[email-masked]>
Date: Fri, 9 Mar 2018 08:45:16 +0800 (CST)

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 <[email-masked]>
收件人：Toerless Eckert <[email-masked]>
抄送人：Greg Shepherd <[email-masked]>BIER WG <[email-masked]>
日 期 ：2018年03月08日 09:55
主 题 ：Re: [Bier] Call for adoption:draft-wijnandsxu-bier-non-mpls-bift-encoding-01

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 

 
 
 Cheers
     Toerless

 On Wed, Mar 07, 2018 at 03:48:17PM -0800, Tony Przygienda wrote:
 > > > > we can not even use the same approach in native (swap the BIFT-ID
 > > > > hop-by-hop.).
 > > >
 > > Eric also didn't answer my question wrt to other encap option/benefits.
 > > Ok. Don't understand why you're stopping there. To me it just means to

--
 ---
 [email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 8 Mar 2018 17:07:52 -0800

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, <[email-masked]> 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)
>
> *发件人：*TonyPrzygienda <[email-masked]>
> *收件人：*Toerless Eckert <[email-masked]>
> *抄送人：*Greg Shepherd <[email-masked]>BIER WG <[email-masked]>
> *日 期 ：*2018年03月08日 09:55
> *主 题 ：**Re: [Bier] Call for
> adoption:draft-wijnandsxu-bier-non-mpls-bift-encoding-01*
>> > > > well, you try the impossible here. You can't have static
>> provisioning
>> > > being
>> > > > that in ethernet encaps extensions in IGP (I smell a draft for
>> people
>> > > right
>> > > > builds consenus having called it) that I'm all dandy to make
>> "BIFT-id
>> > > MUST
>> > > > I'm just one voice but I'll pound most likely with the charter if
>> we try
>> > > to

---

From: <[email-masked]>
Date: Fri, 9 Mar 2018 15:29:27 +0800 (CST)

Hi Tony, Toerless,

Ok. Since the ID can be used by many ways, we can have a discussion about it.

Sandy

原始邮件

发件人：TonyPrzygienda <[email-masked]>
收件人：张征00007940;
抄送人：Toerless Eckert <[email-masked]>Greg Shepherd <[email-masked]>BIER WG <[email-masked]>
日 期 ：2018年03月09日 09:08
主 题 ：Re: [Bier] Call for adoption:draft-wijnandsxu-bier-non-mpls-bift-encoding-01

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 

Hi Tony, hi Toerless,

Thanks,

Sandy

原始邮件

-- tony 

Sure & thanks

 
 Cheers
     Toerless

 On Wed, Mar 07, 2018 at 03:48:17PM -0800, Tony Przygienda wrote:
 > > > telling people which IP addresses to run their DNS servers on ....
 > >

--
 ---
 [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 9 Mar 2018 17:58:20 +0100

Well, if you want to experiment with defining a full BIFT in yang,
we'd need that IMHO more with BIER-TE than BIER first because that one
relies ground up on a controller, and i first need LSR work for
the IGP extensions to create an 'reduced controller dependent' option.

For BIER, the most difficult question to answer unfortunately first
is probably the way how to deal with conflicts between controller
and IGP generation of BIFT entries.

If its sufficient, then we could make this based on some per-domain
or per-sd or per-bift mode-switch.

Or its even based on per-bift-entry (bit) preference: Both IGP
and controller can write info, but it will have different precedence,
and the BIFT will carry highest precedence info (like we do it
for routes in RIBs/FIBs).

I would suggest to go with per-sd mode switch, that allows
co-extance of controller for some sd and igp for others and keeps
it simple. But no strong opinion because i have not concrete
idea of the most important BIER + controller use case to model
the details.

Cheers
    Toerless

On Thu, Mar 08, 2018 at 05:07:52PM -0800, Tony Przygienda wrote:
> > ????????????
> > *????????????*TonyPrzygienda <[email-masked]>
> > *????????????*Toerless Eckert <[email-masked]>
> > *????????????*Greg Shepherd <[email-masked]>BIER WG <[email-masked]>
> > *??? ??? ???*2018???03???08??? 09:55
> > *??? ??? ???**Re: [Bier] Call for

-- 
---
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 9 Mar 2018 09:48:54 -0800

Toerless, thanks, good observation.

My preference would be with a "like route-preference" based approach to
avoid configuring things per SD, per node but it would be interesting to
hear other opinions.  And the static (just like static route) always beats
dynamic normally, worked extremely well in IP routing case ...

Yes, I forgot that in BIER-TE case that may be extremely useful as well ...

--- tony

On Fri, Mar 9, 2018 at 8:58 AM, Toerless Eckert <[email-masked]> wrote:

> > > If it is, we would like to add a readable and writable leafs in the
> YANG
> > > model. Is it enough?
> > >
> > >
> > > Thanks,
> > >
> > > Sandy
> > >
> > >
> > > ????????????
> > >> > c) having standard mapping for network-wide BIFT-id on non-MPLS
> encaps
> > >> (I'm
> > >> > against)
> > >> > > semantic than you're getting yourself into this interpretation
> issue.
> > >> But
> > >> > > the second best solution IMHO, and it would be a lot stronger if
> it
> > >> was
> > >> > > > whole world would still route using static routes and no'one
> would
> > >> bother
> > >> > > for some of my ideas how to mitigate the issue. "Preferred
> standard
> > >> > > semantic"
> > >> > > > people some informational on how encoding is recommended. And
> build
> > >> some
> > >> > > > informational mechanism to discover "misconfiguration" but
> please,
> > >> not as
> > >> > > Its really just based on whether you want to make your and the
> drafts
> > >> life
> > >> > > > > But we do not have a dynamic signaling to automatically
> discover
> > >> thre
> > >> > > > who said. What prevents you from using a "non-MPLS" label space
> and
> > >> > > signal
> > >> > > > > True, but that makes it even more confusing to me why we do
> not
> > >> try to
> > >> > > > > option equivalent to the MPLS encap. This draft is the only
> bit
> > >> missing
> > >> > > > > for that option.
> > >> > > >
> > >> > > > be capable of being out-of-band provisioned on Yang" but I'll
> stop
> > >> at
> > >> > > with making the encoding standard it would become as simple (and
> would
> > >> > > still
> > >> > > > exposing control plane elements to fast path ends up in tears.
> We
> > >> may end
> > >> > > > deployed. There is a very deep reason MPLS labels have no
> structure
> > >> to
> > >> > > > them.
> > >> > >
> > >> > > > > And given how BIER RFCs are targeted to be upgraded from exp
> to
> > >> std,
> > >> > > > scope to "standard" that's a very different kettle of fish &
> Greg
> > >> has to
> > >> > > Of course. Which is why i said i will abstain from a vote right
> now
> > >> > > because i

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Mar 2018 01:50:00 +0100

Ok. you want the most fine/grained/flexible option...

[Ignoring defaults semantics in Yang, no idea yet what that means.]

We create writeable BCTT (Bier Controller Topology Table) with bit entries
like BIRT, each has a preference value. We have a read-only BIRT where we will see
for each bit either the bit semantic from the BCTT if the controller won, or the IGP
learned bit info when the IGP won.  Not sure if/how we would assign preference
to IGP entries. COUld be confgiured default, could be inherited from 
existing IGP Yang model preferences. Not even sure if IGP Yang models include
preference semantic. If theey do we should try to figure out how we can
best be compatible. 

Of course lot more refinemenet needed. Would be good if everything we do could be
declared to be stolen 1:1 from existing yang/igp best practices and 
adopted by considering bfr-id's to be just another address/prefix type.

Cheers
    Toerless 

-- 
---
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 9 Mar 2018 18:00:22 -0800

Toerless, all agreed, worth talking it through and see what emerges. I
don't think we need a new concept like BCCT (or maybe we do) and I think
that we should think whether writing just BIRTs (including next-hops) is
good enough. Maybe it is and we don't even have to write BIFTs but in case
of TE I think we need writable BIFTs as well (but here I would encourage a
split in Yang given that TE really interprets the mask very, very
differently) ... So BIFT-id is just a side-show if the group thinks it's a
good direction to go and work on.

(I never "want it" ;-) but based on other people's long experience I
learned from) in control plane I always strive for the "widest
architecture" which you can call flexible unless complexity or performance
becomes unmanageable. Complexity is structured by keeping things orthogonal
(i.e. exceptions and interactions between things @ minimum), things like
having some special back-off on BIFT-id in one encaps or overlapping pieces
can hog-tie the architecture up over time due to all the exceptions
created. So yes, IMO it's worth hard thinking how to generalize/keep things
clean, it's just brain cycles over beer and dinners comparatively speaking
...  Control plane today performance wise is cheap if done correctly in my
daily experience but yes, there are limits. And otherwise RFC1925 12)
always applies.

In the forwarding path it's the opposite, least amount of abstractions,
very tight encodings,  minimal flexibility, least structure that is
feasible. It's silicon gates and beside power/size/gates the more complex
the fwd' path the buggier the chips and the longer it takes to get anything
working in the field.

And again, we're in STD track, it's a higher standard we will/should be
held up to so the thinking and possibly iteration of different ideas may
tend to take more time. We got the first rush of delivering a good base out
there & deployments have enough to catch up, we have the time I think to do
things we focus now on thoughtfully and well ...

--- tony

On Fri, Mar 9, 2018 at 4:50 PM, Toerless Eckert <[email-masked]> wrote:

> > > > Yes, Sandy, that's what I personally think would be a very good
> property
> > > of
> > > > 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
> > > > > IMO having a writable BIFT-id field for all encaps in the yang
> models
> > > is
> > > > > encoding discussion can continue ... But I forgot all about the
> yang
> > > draft
> > > > >> ask to start brainstorming for the yang modelling of <bsl,si,sd>
> <->
> > > bift
> > > > >> > > > agreed except the mapping cannot be standardized IMO ...
> This is
> > > > >> like
> > > > >> > > > telling people which IP addresses to run their DNS servers
> on
> > > ...
> > > > >> > >
> > > > >> > > fields separately for BSL, SI, SD, we would not have any of
> this
> > > > >> > > discussion.
> > > > >> > >
> > > > >> > > In one assignment, the following 16 bits are SI, SD (BSL
> already
> > > > >> exists
> > > > >> > > 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
> > > > >> > > 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
> > > > >> > > standardized and recommended than if it was just an
> informational
> > > > >> > > suggestion.
> > > > >> > >
> > > > >> > > 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
> > > > >> > > IMHO its exactly the other way around: The most reliably
> working
> > > > >> > > interoperable
> > > > >> > > 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
> > > > >> > > > > find a fully-standardized,most-simple-to-configure
> native-IP
> > > > >> encap
> > > > >> > > end up with a solution thats not as simple as the MPLS
> solution
> > > and
> > > > >> > > > I'm just one voice but I'll pound most likely with the
> charter
> > > if
> > > > >> we try
> > > > >> > > to
> > > > >> > > > up with sub-sub-domain (yeah, I know, just an example) and
> then
> > > > >> what will
> > > > >> > > Sure. But we do not need a label in non-MPLS forwarding. We
> just
> > > need
> > > > >> to
> > > > >> > > know SI,SD.
> > > > >> > > (already have HSL).
> > > > >> > >
> > > > >> > > > > 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
> > > > >> > > love the work, but i think without being standards track its
> just
> > > > >> > > introducing

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Mar 2018 06:10:55 +0100

Will inhale your mail over longer period ;-)

The idea of BCCT was just in reminder that we typically have three
layers - (protocol) topology table, routing table, forwarding table.

In the absence of controller there is IMHO not a lot of difference
between BIRT and BIFT - certainly a lot less than in RIB/FIB or MRIB/MFIB.
So with controller thrown in, what would look like a nice local mapping
of what we want to do to our pre-existing three tier architecture. 
Thats all. Just the question. No answer yet.

My BIER-TE teas draft also proposes some use of the terminology. Similarily
no conclusion yet.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Nabeel Cocker <[email-masked]>
Date: Sat, 10 Mar 2018 17:46:54 -0500

Support. 

Regards,
Nabeel

> On Feb 26, 2018, at 1:07 PM, Greg Shepherd <[email-masked]> wrote:
> 
> In Singapore we had solid support to adopt draft-wijnandsxu-bier-non-mpls-bift-encoding as a WG draft.
> 
> This is a call to the list for adoption. Please read and reply with/without support to this thread:
>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 27 Mar 2018 13:55:44 -0700

We have solid support to adopt this draft as a working group item. There
are still some issues to iron out. Let's keep the discussion moving.

Authors, can you please resubmit with the WG name change and I'll accept.

Cheers,
Greg
(Chairs)