Subject: [Bier] Call for adoption: draft-ietf-bier-non-mpls-bift-encoding

From: Greg Shepherd <[email-masked]>
Date: Fri, 25 Jan 2019 10:13:25 -0800

Please read and reply to this thread with your vote for/against adoption of:

https://datatracker.ietf.org/doc/draft-ietf-bier-non-mpls-bift-encoding/

..as a BIER WG document.

This starts a two week counter.

Thanks,
Chairs
(Shep)

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 25 Jan 2019 12:13:08 -0800

Change of subject. This is WGLC for:

Same two week timer.

Thanks

---

From: Xiejingrong <[email-masked]>
Date: Mon, 28 Jan 2019 02:19:53 +0000

Support WGLC.

I think the two Static BIFT-id encodings are simple and flexible enough for a Domain-unique BIFT-id provisioning, and can help to simplify the deployment.

Jingrong

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Saturday, January 26, 2019 4:13 AM
To: BIER WG <[email-masked]>
Subject: [Bier] WGLC: draft-ietf-bier-non-mpls-bift-encoding

Same two week timer.

Thanks

On Fri, Jan 25, 2019 at 10:13 AM Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
Please read and reply to this thread with your vote for/against adoption of:

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: Senthil Dhanaraj <[email-masked]>
Date: Mon, 28 Jan 2019 14:49:13 +0530

Support !
However, i would like to get couple of clarifications with respect to the
BIFT-id in non-MPLS networks.

1.

Excerpts from section 2.2.1.1 from RFC8296

   In an MPLS network, since the BIFT-id is an MPLS label, its value may
   be changed as a BIER packet goes from BFR to BFR.  In a non-MPLS
   network, since the BIFT-id is domain-wide unique, it is not
expected    // Senthil
   to change as a BIER packet travels.

Senthil// I believe, we do not want to mandate that the BIFT-id must be
domain-wide-unique in case of non-MPLS networks (for the sake of
flexibility).
              If its *not* domain-wide-unique, then the BIFT-id may change
in BFR's as the BIER packet travels from BFIR to BFER.
              Authors & Fellow BIER'ers, let me know what do you think ?

2.

draft-ietf-bier-non-mpls-bift-encoding-01 proposes two encoding methods for
BIFT-id and is mentioned that, both of the encoding options are to derive
"domain-wide-unique: BIFT-id's.

I believe, option-2, that is  "6. The Non-MPLS Static IBU-SI BIFT Encoding",
is flexible and can be used for non-domain-wide-unique BIFT-id's also.

If we agree that, we should allow "non-domain-wide-unique" BIFT-id's for
non-MPLS networks, can we re-phrase the text in
draft-ietf-bier-non-mpls-bift-encoding-01 to specify that, such an encoding
option can be used for non-domain-wide-unique cases as well ?

Thanks,
Senthil

On Sat, Jan 26, 2019 at 1:43 AM Greg Shepherd <[email-masked]> wrote:

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: Xiejingrong <[email-masked]>
Date: Mon, 28 Jan 2019 10:13:07 +0000

Hi Senthil,
I believe the ‘Domain-wide unique’ is the key value of Non-MPLS encapsulation.
Allocation BIFT-id locally on each node is an extra cost, not only in data-plane, but also in control-plane.

That has been concluded in RFC8296 section 2.2.1.1:
   In non-MPLS networks, a BIFT-id MUST be assigned for every
   combination of <SD, SI, BSL> that is to be used in that network.  The
   correspondence between a BIFT-id and a particular <SD, SI, BSL>
   triple is unique throughout the BIER domain and is known to all the
   BFRs in the BIER domain.

The draft we are discussing is to define the above ‘correspondence’  rule.

Jingrong

From: BIER [mailto:[email-masked]] On Behalf Of Senthil Dhanaraj
Sent: Monday, January 28, 2019 5:19 PM
To: Greg Shepherd <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-non-mpls-bift-encoding

Support !
However, i would like to get couple of clarifications with respect to the BIFT-id in non-MPLS networks..

1.

   network, since the BIFT-id is domain-wide unique, it is not expected    // Senthil

Senthil// I believe, we do not want to mandate that the BIFT-id must be domain-wide-unique in case of non-MPLS networks (for the sake of flexibility).
              If its *not* domain-wide-unique, then the BIFT-id may change in BFR's as the BIER packet travels from BFIR to BFER.
              Authors & Fellow BIER'ers, let me know what do you think ?

2.

draft-ietf-bier-non-mpls-bift-encoding-01 proposes two encoding methods for BIFT-id and is mentioned that, both of the encoding options are to derive "domain-wide-unique: BIFT-id's.

I believe, option-2, that is  "6. The Non-MPLS Static IBU-SI BIFT Encoding", is flexible and can be used for non-domain-wide-unique BIFT-id's also.

If we agree that, we should allow "non-domain-wide-unique" BIFT-id's for non-MPLS networks, can we re-phrase the text in draft-ietf-bier-non-mpls-bift-encoding-01 to specify that, such an encoding option can be used for non-domain-wide-unique cases as well ?

Thanks,
Senthil

On Sat, Jan 26, 2019 at 1:43 AM Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:

Same two week timer.

Thanks

..as a BIER WG document.

Thanks,
Chairs
(Shep)
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Mon, 28 Jan 2019 11:17:32 +0000

Hi Senthil,

Thanks for the comments.

See response inline.

> The draft we are discussing is to define the above ‘correspondence’  rule. 

ICE: Agree with Senthil.

> If we agree that, we should allow "non-domain-wide-unique" BIFT-id's for non-MPLS networks, can we re-phrase the text in draft-ietf-bier-non-mpls-bift-encoding-01 to specify that, such an encoding…

ICE: The 'IBU-SI BIFT Encoding’ is indeed flexible, but with that the flexibility is in the way you can add additional future arguments since the IBU is like a Label. But, allowing to change the IBU value from hop-by-hop like MPLS is adding a lot of complexity and we’re re-inventing MPLS. So lets keep this simple and domain side unique.

Thx,

Ice.

---

From: Senthil Dhanaraj <[email-masked]>
Date: Mon, 28 Jan 2019 18:24:28 +0530

Hi Ice/Xiejingrong,

Yes, it is understood that "domain-wide-unique" is advantageous & simple
over "non-domain-wide-unique" BIFT-id's.

And yes, the question about "should we allow non-domain-wide-unique
BIFT-id?" is not exactly arised due to this draft. I've just used the LC
call to seek opinion on the allowing non-domain-wide-unique bift-id's :).
To support non-domain-wide-unique bift-id is based on the real use-case
requirement and i do not have one right now !

So finally to clarify my opinion, "I support WGLC" & move forward. J

Thanks,
Senthil

On Mon, Jan 28, 2019 at 4:47 PM IJsbrand Wijnands (iwijnand) <
[email-masked]> wrote:

> >               If its *not* domain-wide-unique, then the BIFT-id may
> change in BFR's as the BIER packet travels from BFIR to BFER.
> > draft-ietf-bier-non-mpls-bift-encoding-01 proposes two encoding methods
> for BIFT-id and is mentioned that, both of the encoding options are to
> derive "domain-wide-unique: BIFT-id's.
> >
> > I believe, option-2, that is  "6. The Non-MPLS Static IBU-SI BIFT
> Encoding", is flexible and can be used for non-domain-wide-unique BIFT-id's
> also.
> >
> ICE: The 'IBU-SI BIFT Encoding’ is indeed flexible, but with that the
> flexibility is in the way you can add additional future arguments since the
> IBU is like a Label. But, allowing to change the IBU value from hop-by-hop
> like MPLS is adding a lot of complexity and we’re re-inventing MPLS. So
> lets keep this simple and domain side unique.
>
> Thx,
>
> Ice.
>
>
>
> >
> > Thanks,
> > Senthil
> >
> >

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 28 Jan 2019 15:22:36 +0000

I believe the spec is ready to progress beyond the WGLC.

Please see zzh> below for more comments.

> -----Original Message-----
> From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands
> (iwijnand)
> Sent: Monday, January 28, 2019 6:18 AM
> To: Xiejingrong <[email-masked]>
> Cc: Senthil Dhanaraj <[email-masked]>; BIER WG
> <[email-masked]>; Greg Shepherd <[email-masked]>

Zzh> I don't think 'Domain-wide unique' is the KEY value of non-MPLS encapsulation. It's a simplification when you don't need the flexibility provided by non-unique BIFT-IDs.

> > Allocation BIFT-id locally on each node is an extra cost, not only in data-plane, but also in control-plane.

Zzh> I'll defer the advantage and data plane extra cost to later in this email, but control-plane is simple - all you need is a simple local allocation scheme, just like MPLS label allocation. It's a simple task compared to today's sophisticated routing/switching software.

> domain-wide-unique in case of non-MPLS networks (for the sake of flexibility).
> >               If its *not* domain-wide-unique, then the BIFT-id may change in
> BFR's as the BIER packet travels from BFIR to BFER.
> for BIFT-id and is mentioned that, both of the encoding options are to derive
> > I believe, option-2, that is  "6. The Non-MPLS Static IBU-SI BIFT Encoding", is
> flexible and can be used for non-domain-wide-unique BIFT-id's also.
> >
> non-MPLS networks, can we re-phrase the text in draft-ietf-bier-non-mpls-
> bift-encoding-01 to specify that, such an encoding option can be used for non-
> domain-wide-unique cases as well ?
> 
> ICE: The 'IBU-SI BIFT Encoding’ is indeed flexible, but with that the flexibility is
> in the way you can add additional future arguments since the IBU is like a
> Label. But, allowing to change the IBU value from hop-by-hop like MPLS is
> adding a lot of complexity and we’re re-inventing MPLS. So lets keep this
> simple and domain side unique.

I agree that IBU-SI BIFT encoding should still be domain-wide unique encoding.

*** the following is not related to this WGLC ***
*** but I do want to take this opportunity to discuss it ***

I do agree that we should allow local BIFT-IDs just like in MPLS case; but for that the entire 20-bit should be changeable hop by hop (not just the "IBU" part as mentioned above).

In the early days of BIER, we went through significant effort to convince people the advantages of local label based BIFT-ID. It'd be a pity to see that lost in the non-MPLS case. As for additional complexity, it does not have to be implemented like label switching - perhaps just make the BIFT-ID change part of the BIER forwarding (but that's vendor specific). I don't think that's significant extra work compared to BIER lookup/forwarding logic.

If we could reach consensus on this early enough, non-MPLS hardware implementation for BIER may still be able to pick it up.

Jeffrey

> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dnon-2Dmpls-2Dbift-
> 2Dencoding_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=0T5Q66dsW7YDHgsLXzVWk0n7Wqsnx_LH6Qa_ZEVVDEk&s=RDam3fmstw
> EzhanKQR5CKNHdENaisQ4gBoBX-CY_1X0&e=
> >
> > Same two week timer.
> >
> > Thanks
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dnon-2Dmpls-2Dbift-
> 2Dencoding_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=0T5Q66dsW7YDHgsLXzVWk0n7Wqsnx_LH6Qa_ZEVVDEk&s=RDam3fmstw
> EzhanKQR5CKNHdENaisQ4gBoBX-CY_1X0&e=
> >
> > ..as a BIER WG document.
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scb
> fh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=0T5Q66dsW7YDHgsLXzVWk0n7Wqsnx_LH6Qa_ZEVVDEk&s=7ICzSjd3l6JRE
> Uvkr8zzUZY1wrisqrI49LFilosI2R0&e=
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scb
> fh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=0T5Q66dsW7YDHgsLXzVWk0n7Wqsnx_LH6Qa_ZEVVDEk&s=7ICzSjd3l6JRE
> Uvkr8zzUZY1wrisqrI49LFilosI2R0&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scb
> fh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=0T5Q66dsW7YDHgsLXzVWk0n7Wqsnx_LH6Qa_ZEVVDEk&s=7ICzSjd3l6JRE
> Uvkr8zzUZY1wrisqrI49LFilosI2R0&e=

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Mon, 28 Jan 2019 15:24:06 +0000

Support progressing this document.

Thanks
Mankamana

From: BIER <[email-masked]> on behalf of Greg Shepherd <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Friday, January 25, 2019 at 9:13 PM
To: BIER WG <[email-masked]>
Subject: [Bier] WGLC: draft-ietf-bier-non-mpls-bift-encoding

Same two week timer.

Thanks

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 28 Jan 2019 15:27:11 +0000

Support

Regards

Hooman

From: BIER <[email-masked]> On Behalf Of Greg Shepherd
Sent: Friday, January 25, 2019 3:13 PM
To: BIER WG <[email-masked]>
Subject: [Bier] WGLC: draft-ietf-bier-non-mpls-bift-encoding

Same two week timer.

Thanks

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: Akbar Rahman <[email-masked]>
Date: Mon, 28 Jan 2019 15:35:53 +0000

+1 support

From: BIER [mailto:[email-masked]] On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Monday, January 28, 2019 10:27 AM
To: [email-masked]; BIER WG <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-non-mpls-bift-encoding

Support

Regards

Hooman

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Shepherd
Sent: Friday, January 25, 2019 3:13 PM
To: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] WGLC: draft-ietf-bier-non-mpls-bift-encoding

https://datatracker.ietf.org/doc/draft-ietf-bier-non-mpls-bift-encoding/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-non-mpls-bift-encoding%2F&data=02%7C01%7Cakbar.rahman%40interdigital.com%7C0cc2eb3d65a9437cdfcb08d685354a87%7Ce351b779f6d54e50856880e922d180ae%7C0%7C0%7C636842861270800911&sdata=udxWGc2gFERIn4DykpqqKzWbnKpsaz%2F5wOhuVCrx1og%3D&reserved=0>

Same two week timer.

Thanks

https://datatracker.ietf.org/doc/draft-ietf-bier-non-mpls-bift-encoding/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-non-mpls-bift-encoding%2F&data=02%7C01%7Cakbar.rahman%40interdigital.com%7C0cc2eb3d65a9437cdfcb08d685354a87%7Ce351b779f6d54e50856880e922d180ae%7C0%7C0%7C636842861270800911&sdata=udxWGc2gFERIn4DykpqqKzWbnKpsaz%2F5wOhuVCrx1og%3D&reserved=0>

..as a BIER WG document.

Thanks,
Chairs
(Shep)

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 29 Jan 2019 09:32:23 +0800

Support as one co-author.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Greg Shepherd <[email-masked]>
Send Time:2019年1月26日(星期六) 04:13
To:BIER WG <[email-masked]>
Subject:[Bier] WGLC: draft-ietf-bier-non-mpls-bift-encoding

Same two week timer.

Thanks

..as a BIER WG document.

Thanks,
Chairs
(Shep)