Subject: [Bier] RFC8279: Request for authors to update RFC

From: Greg Shepherd <[email-masked]>
Date: Sat, 12 Jun 2021 06:05:16 -0700

A big "thank you" to all WG members who have worked so hard to get BIER to
where it is today. And to no surprise, our work is not done. The following
bullet points are from the Chairs' technical summary previously sent to the
list:

• BIER encoding is specified in RFC8296
• Alia Atlas: “IANA code-points don’t change.  This is the reason why BIER
began as experimental - narrow
        point in hourglass”
• The encoding at the “narrow point of the hourglass” – the forwarding
plane –  is the foundation from which
        the rest of the architecture grows.
• This was the position of the IESG and the BIER WG ADs at the time of the
original WG Experimental Charter.
• This is admittedly historic/institutional knowledge of those involved in
the WG from the beginning. But it is also
        a core tenet of the layered and scalable architecture of the
Internet and was erroneously assumed as
        well-understood by the original WG contributors. The WG needs to
update the BIER architecture to make this
        responsibility clear for all future contributors.

RFC8279 began as a draft at the very beginning of the WG. It has since been
made clear that the authors at that time had assumed the importance of the
forwarding plane as the foundation of architecture was well understood by
the community at large. That no longer seems to be the case. Additionally,
the draft of RFC8279 began before the draft of RFC8296 was complete, and
even before the assignment of the IEEE BIER ethertype.

This is a call for volunteers to update RFC8279 to better define BIER at
the forwarding plane, and clarify how IETF-standard encapsulation
mechanisms can be used to transit BIER packets, while preserving the core
tenet of a layered and scalable architecture of the Internet.

If you would like to tackle this update, please reply to this thread.

Thanks,
Greg
(Chairs)

---

From: <[email-masked]>
Date: Sat, 12 Jun 2021 21:19:26 +0800 (CST)

Hi Gerg, Tony, May I volunteer for the work to help making the description more detailed? Thank you very much! Best regards, Sandy 

原始邮件

发件人:gjshep<[email-masked]>

收件人:bier<[email-masked]>;

日期:2021-06-12 21:05:49

主题:[Bier] RFC8279: Request for authors to update RFC

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

A big "thank you" to all WG members who have worked so hard to get BIER to where it is today. And to no surprise, our work is not done. The following bullet points are from the Chairs' technical summary previously sent to the list: 

•	Alia Atlas: “IANA code-points don’t change.  This is the reason why BIER began as experimental - narrow

        point in hourglass”	

•	The encoding at the “narrow point of the hourglass” – the forwarding plane –  is the foundation from which 

•	This was the position of the IESG and the BIER WG ADs at the time of the original WG Experimental Charter. 	

•	This is admittedly historic/institutional knowledge of those involved in the WG from the beginning. But it is also 

        a core tenet of the layered and scalable architecture of the Internet and was erroneously assumed as 

        well-understood by the original WG contributors. The WG needs to update the BIER architecture to make this 

RFC8279 began as a draft at the very beginning of the WG. It has since been made clear that the authors at that time had assumed the importance of the forwarding plane as the foundation of architecture was well understood by the community at large. That no longer seems to be the case. Additionally, the draft of RFC8279 began before the draft of RFC8296 was complete, and even before the assignment of the IEEE BIER ethertype.

This is a call for volunteers to update RFC8279 to better define BIER at the forwarding plane, and clarify how IETF-standard encapsulation mechanisms can be used to transit BIER packets, while preserving the core tenet of a layered and scalable architecture of the Internet.

Thanks,

Greg

(Chairs)

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 14 Jun 2021 06:46:58 -0700

Thank you, Sandy!

Anyone else willing to help?

Thanks,
Greg
(Chairs)

On Sat, Jun 12, 2021 at 6:19 AM <[email-masked]> wrote:

> Hi Gerg, Tony,
> May I volunteer for the work to help making the description more detailed?
> Thank you very much!
> Best regards,
> Sandy
>
> 原始邮件
> *发件人:*gjshep<[email-masked]>
> *收件人:*bier<[email-masked]>;
> *日期:*2021-06-12 21:05:49
> *主题:**[Bier] RFC8279: Request for authors to update RFC*
>
> • This is admittedly historic/institutional knowledge of those involved
> in the WG from the beginning. But it is also
> RFC8279 began as a draft at the very beginning of the WG. It has since
> been made clear that the authors at that time had assumed the importance of
> the forwarding plane as the foundation of architecture was well understood
> by the community at large. That no longer seems to be the case.
> Additionally, the draft of RFC8279 began before the draft of RFC8296 was
> complete, and even before the assignment of the IEEE BIER ethertype.
>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 14 Jun 2021 14:12:03 +0000

Hi Greg

Just to ensure is the final goal to update 8279 to include bier forwarding with all BIER encapsulation including MPLS, non-MPLS and IPv6 encap? And/Or is it to include bier forwarding over tunnels including mpls, ipv6, for FRR etc… ?

Thanks
Hooman

From: BIER <[email-masked]> On Behalf Of Greg Shepherd
Sent: Monday, June 14, 2021 9:47 AM
To: zhang.zheng <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: Re: [Bier] RFC8279: Request for authors to update RFC

Thank you, Sandy!

Thanks,
Greg
(Chairs)

On Sat, Jun 12, 2021 at 6:19 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gerg, Tony,
May I volunteer for the work to help making the description more detailed?
Thank you very much!
Best regards,
Sandy
原始邮件
发件人:gjshep<[email-masked]<mailto:[email-masked]>>
收件人:bier<[email-masked]<mailto:[email-masked]>>;
日期:2021-06-12 21:05:49
主题:[Bier] RFC8279: Request for authors to update RFC

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier
A big "thank you" to all WG members who have worked so hard to get BIER to where it is today. And to no surprise, our work is not done. The following bullet points are from the Chairs' technical summary previously sent to the list:

Thanks,
Greg
(Chairs)

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 14 Jun 2021 16:22:11 +0200

<individual>

AFAIS the rev should include all the lessons we learned since 8279 was
smote ;-)

Initial architecture was written in a very accessible form, alas could have
benefited from more rigour. Trade-off taken was to move fast with folks who
were largely mind-melted based on long experience in networking & multicast
problems and framework which was malleable rather than formalize things
into a strict corset readable for less experienced folks. The rigour would
benefit us now IMO, especially since lots of work fleshed the details out
and newest discussions show that lots of lessons that old-hands in
multicast learned are not necessarily obvious. Things like "how do you
route underlay?" which led to BAR/IPA discussions or "can you run BIER
without an IGP" which led to lots of yang discussions to allow for
controller only deployments or even BIER-TE which basically uses BIER to
interpret the bitmask completely differently should be codified in 8279bis
IMO.

-- tony

On Mon, Jun 14, 2021 at 4:12 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Hi Greg
>
>
>
> Just to ensure is the final goal to update 8279 to include bier forwarding
> with all BIER encapsulation including MPLS, non-MPLS and IPv6 encap? And/Or
> is it to include bier forwarding over tunnels including mpls, ipv6, for FRR
> etc… ?
>
>
>
> Thanks
>
> Hooman
>
>
>
> *From:* BIER <[email-masked]> *On Behalf Of *Greg Shepherd
> *Sent:* Monday, June 14, 2021 9:47 AM
> *To:* zhang.zheng <[email-masked]>
> *Cc:* BIER WG <[email-masked]>
> *Subject:* Re: [Bier] RFC8279: Request for authors to update RFC
>
>
>
> Thank you, Sandy!
>
>
>
> *发件人**:*gjshep<[email-masked]>
>
> *收件人**:*bier<[email-masked]>;
>
> *日期**:*2021-06-12 21:05:49
>
> *主**题**:[Bier] RFC8279: Request for authors to update RFC*
>

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 14 Jun 2021 13:35:24 -0700

Tony,
Well said. Thanks.

Greg

On Mon, Jun 14, 2021 at 7:22 AM Tony Przygienda <[email-masked]> wrote:

> Initial architecture was written in a very accessible form, alas could
> have benefited from more rigour. Trade-off taken was to move fast with
> folks who were largely mind-melted based on long experience in networking &
> multicast problems and framework which was malleable rather than formalize
> things into a strict corset readable for less experienced folks. The rigour
> would benefit us now IMO, especially since lots of work fleshed the details
> out and newest discussions show that lots of lessons that old-hands in
>> Just to ensure is the final goal to update 8279 to include bier
>> forwarding with all BIER encapsulation including MPLS, non-MPLS and IPv6
>> encap? And/Or is it to include bier forwarding over tunnels including mpls,
>> ipv6, for FRR etc… ?
>>
>>
>>
>> Thanks
>>
>> Hooman
>>
>>
>>
>> A big "thank you" to all WG members who have worked so hard to get BIER
>> to where it is today. And to no surprise, our work is not done. The
>> following bullet points are from the Chairs' technical summary previously
>> sent to the list:
>>
>>
>>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 15 Jun 2021 01:53:02 +0000

I am happy to join the effort.

From: BIER <[email-masked]> On Behalf Of Tony Przygienda
Sent: Monday, June 14, 2021 10:22 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Cc: BIER WG <[email-masked]>; [email-masked]; [email-masked] <[email-masked]>
Subject: Re: [Bier] RFC8279: Request for authors to update RFC

[External Email. Be cautious of content]

<individual>

AFAIS the rev should include all the lessons we learned since 8279 was smote ;-)

Initial architecture was written in a very accessible form, alas could have benefited from more rigour. Trade-off taken was to move fast with folks who were largely mind-melted based on long experience in networking & multicast problems and framework which was malleable rather than formalize things into a strict corset readable for less experienced folks. The rigour would benefit us now IMO, especially since lots of work fleshed the details out and newest discussions show that lots of lessons that old-hands in multicast learned are not necessarily obvious. Things like "how do you route underlay?" which led to BAR/IPA discussions or "can you run BIER without an IGP" which led to lots of yang discussions to allow for controller only deployments or even BIER-TE which basically uses BIER to interpret the bitmask completely differently should be codified in 8279bis IMO.

-- tony

On Mon, Jun 14, 2021 at 4:12 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg

Thanks
Hooman

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Shepherd
Sent: Monday, June 14, 2021 9:47 AM
To: zhang.zheng <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] RFC8279: Request for authors to update RFC

Thank you, Sandy!

Thanks,
Greg
(Chairs)

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!WZyV85iVxS3R5JesZUnDthTZCSH6yL_Lp4Wna_GVdyHfYawiSqvpXDTPXSrhUqdG$>
A big "thank you" to all WG members who have worked so hard to get BIER to where it is today. And to no surprise, our work is not done. The following bullet points are from the Chairs' technical summary previously sent to the list:

Thanks,
Greg
(Chairs)
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!WZyV85iVxS3R5JesZUnDthTZCSH6yL_Lp4Wna_GVdyHfYawiSqvpXDTPXSrhUqdG$>

Juniper Business Use Only

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 15 Jun 2021 02:46:41 +0000

This time replying to all 😊

Thanks for the explanation, sure I can assist.

Regards
Hooman

From: Tony Przygienda <[email-masked]>
Sent: Monday, June 14, 2021 10:22 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Cc: [email-masked]; zhang.zheng <[email-masked]>; BIER WG <[email-masked]>
Subject: Re: [Bier] RFC8279: Request for authors to update RFC

<individual>

-- tony

Thanks
Hooman

Thank you, Sandy!

Thanks,
Greg
(Chairs)

Thanks,
Greg
(Chairs)

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 15 Jun 2021 01:52:48 -0400

I would like to help.

Thanks

Gyan
On Mon, Jun 14, 2021 at 10:46 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> *From:* Tony Przygienda <[email-masked]>
> *Sent:* Monday, June 14, 2021 10:22 AM
> *To:* Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
> *Cc:* [email-masked]; zhang.zheng <[email-masked]>; BIER WG <
> [email-masked]>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 17 Jun 2021 07:36:43 -0700

I believe we have a solid group of volunteers to update the doc:

[email-masked]
[email-masked]
[email-masked]
[email-masked]

Thank you for your continued contribution to the work and for stepping up
to this task.

- Greg
(Chairs)

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 22 Jun 2021 12:28:55 +0200

Greg, *:

I would like to help,... but better not promise more than best effort cycles, which may be rare
under presence of more businss criticial cycles.

I am not quite clear yet, what specifically would be in our out of scope of such
an rfc8279bis? effort. I remember that when we updated PIM-SM for its 'bis RFCs,
someone had collected a long list of issues/improvement suggestions. Maybe
we should have a wiki page on the ietf BIER wiki to allow WG members to contribute
suggestions for improvements to make it easier to track possible work items ?

Working through bier-te-arch for updating to ADs review last weeks, i revisited
some parts of 8279 to better align with them, so some thoughts to help
such a list somewhat cenric to that:

1. Pictures!

  Section 4 might benefit from a picture visualizing the layerin,
  maybe the picture in bier-te-arch could serve as a starting point.

2. Explicitly call out control vs. forwarding plane

  Section 4.2 does not explicitly distinguish between what of its bullet
  point list is BIER layer control plane vs. BIER layer forwarding plane.
  Maybe separating would be nice.

3. distributed vs. decentralized/centralized BIER layer control plane

  The whole document is written (IMHO) so as to imply that the control plane
  is distributed. This is definitely what we defined so far in the WG
  (with ISIS, OSPF), and IMHO the biggest benefit of BIER compared
  to e.g.: BIER-TE which because of its need to engineer the trees
  more naturally depends on a controller.

  Nevertheless, i remember Tony and others to reiterate in past meetings that we could
  also build/implement BIER purely with controller driven conrol plane.
  If it is indeed a goal to open hat door, than such an option might be better documented.

  Example of text that seems to exclude a solely controller based BIER layer control plane:

  (4.2) "Protocols and procedures that a given BFR uses to advertise, to all other BFRs in the same BIER domain"

4. Need for / Role of BIRTs

   If controller driven BIER is of interest, IMHO, one corollary is that
   the BIRTs may be optional, because the way i see it, they really are
   the data structure populated by the local control plane (IGP/BGP), whereas
   a controller based control plane may be beter off directly populating
   the BIFTs. I think it might be easier though to add such thoughts to
   the architecture when we have worked through such thoughts by being
   further along with the BIER yang models (i already tried to help with
   the object model for the BIRT there, i don't think we have even tried
   to define the real BIFT entries in the yang model).

   aka: like in unicast/ip-multicast, BIRT to me would live solidly
   in the BIER layer control plane, required maybe only with distributed
   control plane options, whereas he BIFT is the control plane API into the BIER layer
   forwarding plane, aka: mandatory for any BIER forwarder).

5. Acceptable F-BM for BIFT (impacts implementations)

   If/when we define any yang model for the BIFT, IMHO we would need to
   resolve the question if/what F-BM would have to be acceptable via such
   an API. This would have an impact on the forwarding implementations.

   See slide 8 of my IETF103 preso (https://slidetodoc.com/biertearch-ietf-103-bangkok-draftietfbiertearch01-toerless-eckert-ttecs/ , https://www.youtube.com/watch?v=UBZY4H6Ql_I&t=13s at 1:31:00 )

6. Which layer does the IGP live in ? 

   One of the corollaries not explicitly called out for in 8279 is that
   AFAIK, the IGP itself seems to live in the conrol plane of the routing
   underlay, whereas the BIER extensions of the IGP would live in the
   control plane of the BIER layer. 

   Aka: the fact that a single control plane (IGP) protocol may stretch across
   the layers of the BIER architecture may be something to explicitly call out,
   because this may be somewhat counterintuitive to readers oherwise.

6. API between Flow overlay and BIER layer on BFIR and BFER

   If/when we wanted to ensure that Flow overlay and BIER layer could be
   developed independendly on BFIR/BFER (think linux where BIER is implemented
   once and different apps/overlays want to use it), we may want to have a
   somewhat more formalized abstract API definition for the BIER layer.

   Thought experiment: I build on linux BFIR/BFER some flow overlay based on
   an available MPLS based BIER layer implementation. Then comes along
   draft-ietf-bier-non-mpls-bift-encoding an the BIER layer is extended to
   support e.g. BIER directly over ethernet. Q: should/could we have
   defined upfront the BIER-layer to flow overlay API such that i would not
   have to go back updating/modifying the flow overlay implementation ?
   I think that would be lovely. Have we given implementers all the help we
   shuold to enable that ?

   This goes primarily back to do we expose BIFT-id to flow overlay,
   and what happens if such in hat draft its semantic changes.

Cheers
    Toerless
   
On Sat, Jun 12, 2021 at 06:05:16AM -0700, Greg Shepherd wrote:
> ??? BIER encoding is specified in RFC8296
> ??? Alia Atlas: ???IANA code-points don???t change.  This is the reason why BIER
>         point in hourglass???
> ??? The encoding at the ???narrow point of the hourglass??? ??? the forwarding
> plane ???  is the foundation from which
> ??? This was the position of the IESG and the BIER WG ADs at the time of the
> ??? This is admittedly historic/institutional knowledge of those involved in

-- 
---
[email-masked]

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 28 Jun 2021 11:44:02 +0800

Hi, Toerless:

Related to your 3rd point(centralized BIER layer control plane), we have
summited one draft
https://datatracker.ietf.org/doc/html/draft-li-pce-pcep-extension-multicast-
management-00.txt to cover this topic.
The updated version of this draft will be provided soon in these days, and
we would like to make one introduction for this draft in the coming IETF
meeting.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Toerless
Eckert
Sent: Tuesday, June 22, 2021 6:29 PM
To: Greg Shepherd <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: Re: [Bier] RFC8279: Request for authors to update RFC

Greg, *:

I would like to help,... but better not promise more than best effort
cycles, which may be rare under presence of more businss criticial cycles.

I am not quite clear yet, what specifically would be in our out of scope of
such an rfc8279bis? effort. I remember that when we updated PIM-SM for its
'bis RFCs, someone had collected a long list of issues/improvement
suggestions. Maybe we should have a wiki page on the ietf BIER wiki to allow
WG members to contribute suggestions for improvements to make it easier to
track possible work items ?

Working through bier-te-arch for updating to ADs review last weeks, i
revisited some parts of 8279 to better align with them, so some thoughts to
help such a list somewhat cenric to that:

1. Pictures!

  Nevertheless, i remember Tony and others to reiterate in past meetings
that we could
  also build/implement BIER purely with controller driven conrol plane.
  If it is indeed a goal to open hat door, than such an option might be
better documented.

  Example of text that seems to exclude a solely controller based BIER layer
control plane:

  (4.2) "Protocols and procedures that a given BFR uses to advertise, to all
other BFRs in the same BIER domain"

   the data structure populated by the local control plane (IGP/BGP),
whereas

   aka: like in unicast/ip-multicast, BIRT to me would live solidly
   in the BIER layer control plane, required maybe only with distributed
   control plane options, whereas he BIFT is the control plane API into the
BIER layer
   forwarding plane, aka: mandatory for any BIER forwarder).

   See slide 8 of my IETF103 preso
(https://slidetodoc.com/biertearch-ietf-103-bangkok-draftietfbiertearch01-to
erless-eckert-ttecs/ , https://www.youtube.com/watch?v=UBZY4H6Ql_I&t=13s at
1:31:00 )

   Aka: the fact that a single control plane (IGP) protocol may stretch
across
   the layers of the BIER architecture may be something to explicitly call
out,
   because this may be somewhat counterintuitive to readers oherwise.

   If/when we wanted to ensure that Flow overlay and BIER layer could be
   developed independendly on BFIR/BFER (think linux where BIER is
implemented
   once and different apps/overlays want to use it), we may want to have a
   somewhat more formalized abstract API definition for the BIER layer.

Cheers
    Toerless
   
On Sat, Jun 12, 2021 at 06:05:16AM -0700, Greg Shepherd wrote:
> A big "thank you" to all WG members who have worked so hard to get 
> BIER to where it is today. And to no surprise, our work is not done. 
> The following bullet points are from the Chairs' technical summary 
> previously sent to the
> list:
> 
> ??? BIER encoding is specified in RFC8296 ??? Alia Atlas: ???IANA 
> code-points don???t change.  This is the reason why BIER began as 
> experimental - narrow
>         point in hourglass???
> ??? The encoding at the ???narrow point of the hourglass??? ??? the 
> forwarding plane ???  is the foundation from which
> ??? This was the position of the IESG and the BIER WG ADs at the time 
> of the original WG Experimental Charter.
> ??? This is admittedly historic/institutional knowledge of those 
> involved in the WG from the beginning. But it is also
>         well-understood by the original WG contributors. The WG needs 
> to update the BIER architecture to make this
> been made clear that the authors at that time had assumed the 
> importance of the forwarding plane as the foundation of architecture 
> was well understood by the community at large. That no longer seems to 
> be the case. Additionally, the draft of RFC8279 began before the draft 
> of RFC8296 was complete, and even before the assignment of the IEEE BIER
ethertype.
> 
> This is a call for volunteers to update RFC8279 to better define BIER 
> at the forwarding plane, and clarify how IETF-standard encapsulation 
> mechanisms can be used to transit BIER packets, while preserving the 
> core tenet of a layered and scalable architecture of the Internet.
> 

--
---
[email-masked]

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 28 Jun 2021 10:40:29 -0700

Thanks Toerless. All good suggestions, and valuable input. I'm certain
Sandy will welcome your help.

Cheers,
Greg

On Tue, Jun 22, 2021 at 3:29 AM Toerless Eckert <[email-masked]> wrote:

> cycles, which may be rare
> revisited
>    See slide 8 of my IETF103 preso (
> https://slidetodoc.com/biertearch-ietf-103-bangkok-draftietfbiertearch01-toerless-eckert-ttecs/
> , https://www.youtube.com/watch?v=UBZY4H6Ql_I&t=13s at 1:31:00 )
>
> to
> involved in
> been

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 29 Jun 2021 01:22:17 +0200

Thanks, Greg.

Would be great if any work towards bis'ing the RFC would be set up openy
enough such that this type of help/support will continue to be possible
(e.g.: if there is a DT style approach, pls. make it open).

Cheers
   toerless

-- 
---
[email-masked]

---

From: 'Toerless Eckert' <[email-masked]>
Date: Tue, 29 Jun 2021 01:27:25 +0200

Thanks. Added to reading list.

given how you have named this -pce- (and not -bier-), it will not show up automatically
on the BIER WG datatracker list of associated documents. If this is
meant to be read by BIER folks, please ask BIER chairs to have this
doc associated with BIER on datatracker (few clicks for a chair on datatracker!)

Cheers
    Toerless

-- 
---
[email-masked]

---

From: <[email-masked]>
Date: Tue, 29 Jun 2021 11:39:46 +0800 (CST)

Yes. Thanks Toerless very much for your suggestion!
Will consider your suggestion carefully.
Welcom to join our work! :-)
Best regards,
Sandy

------------------原始邮件------------------
发件人：GregShepherd
收件人：Toerless Eckert;
抄送人：BIER WG;
日 期 ：2021年06月29日 01:41
主 题 ：Re: [Bier] RFC8279: Request for authors to update RFC
_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

Thanks Toerless. All good suggestions, and valuable input. I'm certain Sandy will welcome your help.

Cheers,
Greg

--
---
[email-masked]

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 29 Jun 2021 19:09:42 +0000

I can help too.

From: BIER <[email-masked]> on behalf of Greg Shepherd <[email-masked]>
Date: Saturday, June 12, 2021 at 6:05 AM
To: BIER WG <[email-masked]>
Subject: [Bier] RFC8279: Request for authors to update RFC
A big "thank you" to all WG members who have worked so hard to get BIER to where it is today. And to no surprise, our work is not done. The following bullet points are from the Chairs' technical summary previously sent to the list:

Thanks,
Greg
(Chairs)