Subject: Re: [Bier] BIER/IPv6 Requirements and Solutions

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 18 Sep 2020 02:48:42 +0000

Hello Alvaro, Wg,
Firstly thank you alvaro and the chairs for the clear directing!
The new requirements draft had been posted, please read and see if the direction is correctly followed and if your comments are addressed.
Your further comments, corrections, complaints, compliments are all welcome.

Thanks
Jingrong

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]] 
Sent: Friday, August 7, 2020 10:19 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: BIER/IPv6 Requirements and Solutions

Hello all!

I am directing this message to the authors of the BIER in IPv6-related work.  I am also copying the WG because this work needs more engagement[*], making sure I don't miss anyone.

  [*] More engagement in the form of substantive discussions from non-
  authors, and diversity of affiliations.

Some of you raised concerns to the IESG about the speed at which the IPv6-related work has been moving, and the ability to discuss it during WG meetings.  In response, I am providing my opinion of the current state and, after consultation with the Chairs, reinforcing the required steps to move any work forward.

Note that my intent is not to insert myself in the discussions, but to get them back on track.  All decisions should be made by WG consensus as interpreted by the Chairs [rfc2418].

I have done a preliminary/high-level review of the requirements document (see details below); I don't think it currently is in a state to provide adequate material for WG discussion.  Besides specific requirements, the text should include a clear justification for the WG to reach a consensus.  The current version doesn't properly cover these aspects.

The document points to the WG Charter in a couple of places as justification for the work.  Recommendation: Focus on the technical aspects and not whether something is in the Charter or not!  If there is WG consensus, a Charter can be amended to include new work.  On the other hand, while a Charter is used to provide scope and focus, it must not be used as justification for doing work in the absence of discussion and consensus.

The critical step towards adopting a solution (or solutions) is engaged discussion of the requirements.  After looking at the document (comments below), I don't think it provides a good base for analysis.
The expectation is for the requirements to be clear, specific, measurable, and to justify their applicability in the solution.

In consultation with the Chairs, we expect a revised requirements document *before* IETF 109.  As I mentioned above, more engagement is needed in its development.  Ideally, the text will be discussed on the list as it evolves.  If a live discussion is required, the Chairs will organize one (an interim meeting, if there is enough time before IETF 109).

Greg is the Chair responsible for this process.  [Side note: Tony has decided to remove himself as co-author of one of the proposals.  His comments will be considered as coming from a WG participant.]

If anyone has concerns about this message, please contact me directly.
Again, I won't participate in the WG discussions, but (if needed) may provide additional feedback related to my review of
draft-ietf-bier-ipv6-requirements-06 (below).

Thanks!!

Alvaro.

Review of draft-ietf-bier-ipv6-requirements-06

This is an informal review.  While I expect this document to serve as a discussion point for the WG, and for it to *not* be published as an RFC, I have strong concerns about its contents.

Note that the intent of providing a review at this point is to aid in progressing the IPv6-related discussion.  Any consensus on the specific requirements should come from the WG, guided by the Chairs.

Consider all my comments as my personal opinion.

===

In general, the requirements listed are either too vague or not well justified.  The objective "to help the BIER WG evaluate the BIER v6 requirements" cannot be met unless there is clarity that can lead to engaged discussion.

The document starts by explaining the problem space (from the Introduction):

   As clarified in the working-group, "BIER natively in IPv6" means BIER not
   encapsulated in MPLS or Ethernet.  This may include native IPv6
   encapsulation and generic IPv6 tunnelling.

I didn't look at the archive, but I'm sure the WG can do a better job!!

This description is vague (""...natively in IPv6" means BIER not encapsulated in MPLS or Ethernet"), recursive (native "may include
native") and confusing (native "may include native...and...tunnelling [sic]").

Note that the Problem Statement itself ("to transport BUM packets, with BIER headers, in an IPv6 environment.") is straightforward -- the expectation of what is required as a solution is not.

Two conceptual solution models are presented.  The description of the "Transport-Independent Model" is not in line with the layering model from rfc8279.  In the best case, the terminology doesn't match; but I think that the description might introduce new concepts.  Note also that the statement that "BIER-MPLS could use this approach directly since BIER-MPLS is based on MPLS" seems to contradict the definition of "natively in IPv6".

The description of the "Native IPv6 Model" gets a slightly different treatment; for example, it includes benefits.  Note that this model also mentions "a trusted IPv6-based domain" while comparing the model to SRv6, *and* talking about a "wider inter-AS scope".  These seem to be contradictions as a trusted domain is typically aligned to a single administrative entity [rfc8402].  Again, the terminology may not be in alignment...or more discussion may be needed on the scope.

On to the requirements.  As far as requirement levels go, I recommend that you use three levels instead of two: required, recommended, and optional.  The level should be justified depending on the potential deployment or solution model.

Some of the mandatory requirements listed are obvious and probably don't need even to be mentioned.  That is the case for:

352	4.1.2.  Support BIER architecture
361	4.1.3.  Conform to existing IPv6 Spec
368	4.1.4.  Support deployment with Non-BFR routers

Some of the requirements are not clear -- they need a better description and clear justification.

345	4.1.1.  L2 Agnostic

347	   The solution must be agnostic to the underlying L2 data link type.
348	   The solution needs to support P2P ethernet links as well as shared
349	   media ethernet links without requiring the LAN switch to perform BIER
350	   snooping.

Agnostic to the L2 data link, but also needs to support specific topologies.  That is a contradiction.  Also, where is "BIER snooping"
defined?

376	4.1.5.  Support inter-AS multicast deployment

378	   Inter-AS multicast support is needed for ease of provisioning the
379	   P2MP transport service to enterprises.  This could greatly increase
380	   the scalability of BIER, as it is usually considered to be suitable
381	   only for small intra-AS scenarios.

rfc8279 talks about a single BIER domain.  There is no discussion about BIER domains in the context of inter-AS operation in this draft or draft-geng-bier-ipv6-inter-domain.  Again, in the best case, we have a terminology mismatch. Still, it is not clear if the text proposes new functionality -- and using draft-geng-bier-ipv6-inter-domain as the base for a mandatory requirement doesn't seem correct without WG consensus.

383	4.1.6.  Support Simple Encapsulation

385	   The solution must avoid requiring different encapsulation types.  A
386	   solution needs to do careful trade-off analysis and select one
387	   encapsulation as its proposal for best coverage of various scenarios.

Based on the description of "natively in IPv6", it seems like anything that is "not encapsulated in MPLS or Ethernet" should be ok.  What is the justification behind one encapsulation?  It sounds like this requirement opens the door to multiple solutions, each with different encapsulations -- doesn't that contradict a mandatory requirement of one?

Finally, we find the security requirement:

389	4.1.7.  Support Deployment Security

391	   The proposed solution must include careful security considerations,
392	   including all that is already considered in BIER architecture RFC8279
393	   and RFC8296, and other security concerns that may raise due to the
394	   addition of IPv6.

I want to highlight the obvious nature of "must include careful security considerations", which is a documentation issue -- there are no specific security requirements on the solution itself?  No particular mention of any security aspect.  What is the technical need?  :-(

The optional requirements don't fare much better.  In general, please clarify and justify them.

Some of the optional requirements seem to be associated with unexplained scenarios.  For example, the support for MVPN or IPSEC...and the specific need to forward "in hardware fast path".

Others seem to make improper assumptions (for example, as far as I know, there is no existing standard OAM method) or suggest potential enhancements ("enhance the capability of BIER leveraging the BIER-MTU"
 ??).

In summary, the list of requirements presented is not clear or adequately justified.  It is not conducive to a WG discussion about the requirements themselves...much less about potential solutions.

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 18 Sep 2020 08:47:11 -0700

Jingrong,

Sorry, no, it doesn't appear that much of the direction provided by WG
members on the list, nor the WG Chairs, nor the AD was heeded at all. A
requirements document needs to provide requirements - only. This doc is
still mistakenly written as a solutions comparison marketing doc - Section
3 does not belong in this doc. The purpose of the reqs doc is to provide a
guide for the WG to follow in determining 1) IF a new encap is needed, and
if so, 2) what any proposed solution needs to address that cannot be
addressed with the available tools today. ONLY then will this doc provide
the guidance we need to evaluate 1).

It's clear to me the current authors have little intention of following the
direction of the WG. At this time I recommend that we either:

1) Replace/refresh the authors with people willing to work with the BIER WG
members at large, and within the guidlines of the IETF.

or

2) de-adopt this document entirely. The WG as a whole can determine if I
wishes to restart this effort.

- Shep
(chairs)

On Thu, Sep 17, 2020 at 7:48 PM Xiejingrong (Jingrong) <
[email-masked]> wrote:

> The new requirements draft had been posted, please read and see if the
> direction is correctly followed and if your comments are addressed.
> To: [email-masked];
> [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> I am directing this message to the authors of the BIER in IPv6-related
> work.  I am also copying the WG because this work needs more engagement[*],
> making sure I don't miss anyone.
>
> Some of you raised concerns to the IESG about the speed at which the
> IPv6-related work has been moving, and the ability to discuss it during WG
> meetings.  In response, I am providing my opinion of the current state and,
> after consultation with the Chairs, reinforcing the required steps to move
> any work forward.
>
> Note that my intent is not to insert myself in the discussions, but to get
> them back on track.  All decisions should be made by WG consensus as
> interpreted by the Chairs [rfc2418].
>
>
> I have done a preliminary/high-level review of the requirements document
> (see details below); I don't think it currently is in a state to provide
> adequate material for WG discussion.  Besides specific requirements, the
> text should include a clear justification for the WG to reach a consensus.
> The current version doesn't properly cover these aspects.
>
> The document points to the WG Charter in a couple of places as
> justification for the work.  Recommendation: Focus on the technical aspects
> and not whether something is in the Charter or not!  If there is WG
> consensus, a Charter can be amended to include new work.  On the other
> hand, while a Charter is used to provide scope and focus, it must not be
> used as justification for doing work in the absence of discussion and
> consensus.
>
>
> The critical step towards adopting a solution (or solutions) is engaged
> discussion of the requirements.  After looking at the document (comments
> below), I don't think it provides a good base for analysis.
> The expectation is for the requirements to be clear, specific, measurable,
> and to justify their applicability in the solution.
>
> In consultation with the Chairs, we expect a revised requirements document
> *before* IETF 109.  As I mentioned above, more engagement is needed in its
> development.  Ideally, the text will be discussed on the list as it
> evolves.  If a live discussion is required, the Chairs will organize one
> (an interim meeting, if there is enough time before IETF 109).
>
> Greg is the Chair responsible for this process.  [Side note: Tony has
> decided to remove himself as co-author of one of the proposals.  His
> comments will be considered as coming from a WG participant.]
>
>
> Again, I won't participate in the WG discussions, but (if needed) may
> provide additional feedback related to my review of
> This is an informal review.  While I expect this document to serve as a
> discussion point for the WG, and for it to *not* be published as an RFC, I
> have strong concerns about its contents.
>
> Note that the intent of providing a review at this point is to aid in
> progressing the IPv6-related discussion.  Any consensus on the specific
> requirements should come from the WG, guided by the Chairs.
>
> In general, the requirements listed are either too vague or not well
> justified.  The objective "to help the BIER WG evaluate the BIER v6
> requirements" cannot be met unless there is clarity that can lead to
> engaged discussion.
>
>
> This description is vague (""...natively in IPv6" means BIER not
> encapsulated in MPLS or Ethernet"), recursive (native "may include
> Note that the Problem Statement itself ("to transport BUM packets, with
> BIER headers, in an IPv6 environment.") is straightforward -- the
> expectation of what is required as a solution is not.
>
>
> Two conceptual solution models are presented.  The description of the
> "Transport-Independent Model" is not in line with the layering model from
> rfc8279.  In the best case, the terminology doesn't match; but I think that
> the description might introduce new concepts.  Note also that the statement
> that "BIER-MPLS could use this approach directly since BIER-MPLS is based
> on MPLS" seems to contradict the definition of "natively in IPv6".
>
> The description of the "Native IPv6 Model" gets a slightly different
> treatment; for example, it includes benefits.  Note that this model also
> mentions "a trusted IPv6-based domain" while comparing the model to SRv6,
> *and* talking about a "wider inter-AS scope".  These seem to be
> contradictions as a trusted domain is typically aligned to a single
> administrative entity [rfc8402].  Again, the terminology may not be in
> alignment...or more discussion may be needed on the scope.
>
>
>
> On to the requirements.  As far as requirement levels go, I recommend that
> you use three levels instead of two: required, recommended, and optional.
> The level should be justified depending on the potential deployment or
> solution model.
>
>
> Some of the mandatory requirements listed are obvious and probably don't
> need even to be mentioned.  That is the case for:
>
> Agnostic to the L2 data link, but also needs to support specific
> topologies.  That is a contradiction.  Also, where is "BIER snooping"
> defined?
>
>
> rfc8279 talks about a single BIER domain.  There is no discussion about
> BIER domains in the context of inter-AS operation in this draft or
> draft-geng-bier-ipv6-inter-domain.  Again, in the best case, we have a
> terminology mismatch. Still, it is not clear if the text proposes new
> functionality -- and using draft-geng-bier-ipv6-inter-domain as the base
> for a mandatory requirement doesn't seem correct without WG consensus.
>
>
> Based on the description of "natively in IPv6", it seems like anything
> that is "not encapsulated in MPLS or Ethernet" should be ok.  What is the
> justification behind one encapsulation?  It sounds like this requirement
> opens the door to multiple solutions, each with different encapsulations --
> doesn't that contradict a mandatory requirement of one?
>
>
> I want to highlight the obvious nature of "must include careful security
> considerations", which is a documentation issue -- there are no specific
> security requirements on the solution itself?  No particular mention of any
> security aspect.  What is the technical need?  :-(
>
>
> Some of the optional requirements seem to be associated with unexplained
> scenarios.  For example, the support for MVPN or IPSEC...and the specific
> need to forward "in hardware fast path".
>
> Others seem to make improper assumptions (for example, as far as I know,
> there is no existing standard OAM method) or suggest potential enhancements
> ("enhance the capability of BIER leveraging the BIER-MTU"
>  ??).
>
>
> In summary, the list of requirements presented is not clear or adequately
> justified.  It is not conducive to a WG discussion about the requirements
> themselves...much less about potential solutions.
>

---

From: Michael McBride <[email-masked]>
Date: Fri, 18 Sep 2020 22:41:37 +0000

Hi Greg, all,

I understand the ietf enjoys harsh critiques of drafts but we can probably do better by occasionally sprinkling in some appreciation. I would like to thank all the authors for their hard work on this draft, particularly the most recent editing from Jeffrey, Gyan and Jingrong.

We feel the draft serves its purpose and are quite proud of the work. If the wg agrees with Greg’s assessment then yes, we aren’t the right authors, for this requirements draft, and will move on. Otherwise we are anticipating additional editing per wg advice.

Thanks,
mike

From: Greg Shepherd <[email-masked]>
Sent: Friday, September 18, 2020 8:47 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: BIER/IPv6 Requirements and Solutions

Jingrong,

Sorry, no, it doesn't appear that much of the direction provided by WG members on the list, nor the WG Chairs, nor the AD was heeded at all. A requirements document needs to provide requirements - only. This doc is still mistakenly written as a solutions comparison marketing doc - Section 3 does not belong in this doc. The purpose of the reqs doc is to provide a guide for the WG to follow in determining 1) IF a new encap is needed, and if so, 2) what any proposed solution needs to address that cannot be addressed with the available tools today. ONLY then will this doc provide the guidance we need to evaluate 1).

It's clear to me the current authors have little intention of following the direction of the WG. At this time I recommend that we either:

1) Replace/refresh the authors with people willing to work with the BIER WG members at large, and within the guidlines of the IETF.

or

2) de-adopt this document entirely. The WG as a whole can determine if I wishes to restart this effort.

- Shep
(chairs)

On Thu, Sep 17, 2020 at 7:48 PM Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Alvaro, Wg,
Firstly thank you alvaro and the chairs for the clear directing!
The new requirements draft had been posted, please read and see if the direction is correctly followed and if your comments are addressed.
Your further comments, corrections, complaints, compliments are all welcome.

Thanks
Jingrong

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 7, 2020 10:19 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: BIER/IPv6 Requirements and Solutions

Hello all!

Thanks!!

Alvaro.

===

345     4.1.1.  L2 Agnostic

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 24 Sep 2020 01:39:43 -0400

Greg

With all do respect, the authors welcome the AD and Chairs criticism and
any feedback, however in this particular case with your response, there
seems to be a disconnect with the ML discussions we have had over the last
several months.  Understandably, all of us here in the WG realize the
criticality of the BIER in an IPv6 environment, and that BIER-MPLS &
BIER-Ethernet, as it stands today has a MAJOR gap in being able to support
SRv6 Service Provider core technology requiring an IPv6 data plane, which
will be the end all be all replacement for MPLS.  It is critical that the
BIER WG come up with a solution(s) that supports an IPv6 data plane for
SRv6 support.  We all don't want BIER to die on the vine in a technology
graveyard with ATM, Frame Relay and the likes.  We the authors are all in
agreement and running fast after that goal and understand the AD & Chairs
now emphasis on the requirements draft.  We are with you lock, stock and
barrel.

The authors of the BIER IPv6 Solutions draft
“draft-xie-bier-ipv6-encapsulation-08”, BIERv6, referred to as the
“Integrated model”, authors myself, McBride, Xuesong & Jingrong
 collaborated in a joint effort over a month timeframe with the authors of
the BIER IPv6 Solutions draft “draft-zhang-bier-bierin6-07”, BIERin6,
referred to as the Independent model , authors Jeffrey & Sandy to come up
with a holistic solution where both conceptual models accurately addressed
the problem statement as well as the requirements to support IPv6 for SRv6
support.  We wanted to make sure that we had complete parity between
conceptual models and relationships to the problem statement and
requirements list.  All authors from both solutions worked together to
ensure we had all of our “i’s” dotted & “t’s” crossed so to speak, putting
our best foot forward with this rev 7.

I would like to point out that given the “Integrated model” BIERv6
Solutions initial draft came out in April 2018, and the “Independent model”
BIERin6 Solution came out in October 2017.  It is only since January 2019
initial draft submission has the work to reverse engineer to come up with
the Requirements draft started a “post mortem” so to speak after the
Solutions had already been proposed.  To that end in IETF108, the
requirements draft had positive feedback related to Section 3 conceptual
framework for the two solutions proposed.  We are all at a loss in
understanding your comments as to removal of section 3.  In order to create
a requirements draft as part of any basic requirements analysis, you must
have some idea or concept or inkling of a solutions framework to graft &
glean the list of requirements which otherwise is not possible in my mind.

If I had my druthers and we lived in a perfect world, it would have been
nice to have completed the requirements draft prior to developing the
solutions which now came before the egg so to speak.

Please keep in mind the “which comes first issue here– "chicken or the egg
scenario” in our case the chicken being the solution draft's, and now we
are working “bass-ackwards” with razor focus now after the fact back on the
requirements which was missed at the get-go.

The WG Charter does have verbiage that is inclusive of BIER in IPv6 and
does use the word “native” even though that has caused confusion and we
have eliminated it from the requirements draft  - excerpt below.

7) BIER in IPv6 : A mechanism to use BIER natively in IPv6 may be
standardized if coordinated with the 6MAN WG and with understood
applicability.

The problem statement is crystal clear that the challenge now is how and
where to encode BIER header in an IPV6 environment.  Plain and simple.

Dear BIER WG,

We the authors welcome all WG participants on the ML to help collectively
define & further define the conceptual models, as well as address any
deficiencies with the requirements we have put together in the draft
rev-7.  I would like to make it clear that none of us authors are married
to any solution and we welcome all ideas and solutions.

We are all striving to keep an open mind thinking outside the box, so we
don’t box ourselves into any one solution, and are open to look at any and
all options or solutions out there.

We all want to be successful in coming up with a BIER solution that
supports SRv6 the “end all be all” replacement for MPLS.

Kind Regards,

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

On Fri, Sep 18, 2020 at 11:47 AM Greg Shepherd <[email-masked]> wrote:

> It's clear to me the current authors have little intention of following
> the direction of the WG. At this time I recommend that we either:
>
> 1) Replace/refresh the authors with people willing to work with the BIER
> WG members at large, and within the guidlines of the IETF.
>
> or
>
>> Note that my intent is not to insert myself in the discussions, but to
>> get them back on track.  All decisions should be made by WG consensus as
>> The expectation is for the requirements to be clear, specific,
>> measurable, and to justify their applicability in the solution.
>>
>> In consultation with the Chairs, we expect a revised requirements
>> document *before* IETF 109.  As I mentioned above, more engagement is
>> needed in its development.  Ideally, the text will be discussed on the list
>> as it evolves.  If a live discussion is required, the Chairs will organize
>> one (an interim meeting, if there is enough time before IETF 109).
>>
>> On to the requirements.  As far as requirement levels go, I recommend
>> that you use three levels instead of two: required, recommended, and
>> optional.  The level should be justified depending on the potential
>> deployment or solution model.
>>
>>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 24 Sep 2020 09:44:52 +0000

Hi Gyan,

A small clarification - while the requirements draft -07 currently does have sections that briefly describe different models/solutions, we have avoided discussing which one satisfies which requirements intentionally (as the focus is on listing requirements).

With that, I don't think we've got a conclusion that "BIER-MPLS & BIER-Ethernet, as it stands today has a MAJOR gap in being able to support SRv6 Service Provider core technology requiring an IPv6 data plane".

Jeffrey

Juniper Business Use Only
From: Gyan Mishra <[email-masked]>
Sent: Thursday, September 24, 2020 1:40 AM
To: Greg Shepherd <[email-masked]>
Cc: Xiejingrong (Jingrong) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Alvaro Retana <[email-masked]>
Subject: Re: [Bier] BIER/IPv6 Requirements and Solutions

[External Email. Be cautious of content]

Greg

With all do respect, the authors welcome the AD and Chairs criticism and any feedback, however in this particular case with your response, there seems to be a disconnect with the ML discussions we have had over the last several months.  Understandably, all of us here in the WG realize the criticality of the BIER in an IPv6 environment, and that BIER-MPLS & BIER-Ethernet, as it stands today has a MAJOR gap in being able to support SRv6 Service Provider core technology requiring an IPv6 data plane, which will be the end all be all replacement for MPLS.  It is critical that the BIER WG come up with a solution(s) that supports an IPv6 data plane for SRv6 support.  We all don't want BIER to die on the vine in a technology graveyard with ATM, Frame Relay and the likes.  We the authors are all in agreement and running fast after that goal and understand the AD & Chairs now emphasis on the requirements draft.  We are with you lock, stock and barrel.

The authors of the BIER IPv6 Solutions draft "draft-xie-bier-ipv6-encapsulation-08", BIERv6, referred to as the "Integrated model", authors myself, McBride, Xuesong & Jingrong  collaborated in a joint effort over a month timeframe with the authors of the BIER IPv6 Solutions draft "draft-zhang-bier-bierin6-07", BIERin6, referred to as the Independent model , authors Jeffrey & Sandy to come up with a holistic solution where both conceptual models accurately addressed the problem statement as well as the requirements to support IPv6 for SRv6 support.  We wanted to make sure that we had complete parity between conceptual models and relationships to the problem statement and requirements list.  All authors from both solutions worked together to ensure we had all of our "i's" dotted & "t's" crossed so to speak, putting our best foot forward with this rev 7.

I would like to point out that given the "Integrated model" BIERv6 Solutions initial draft came out in April 2018, and the "Independent model" BIERin6 Solution came out in October 2017.  It is only since January 2019 initial draft submission has the work to reverse engineer to come up with the Requirements draft started a "post mortem" so to speak after the Solutions had already been proposed.  To that end in IETF108, the requirements draft had positive feedback related to Section 3 conceptual framework for the two solutions proposed.  We are all at a loss in understanding your comments as to removal of section 3.  In order to create a requirements draft as part of any basic requirements analysis, you must have some idea or concept or inkling of a solutions framework to graft & glean the list of requirements which otherwise is not possible in my mind.

If I had my druthers and we lived in a perfect world, it would have been nice to have completed the requirements draft prior to developing the solutions which now came before the egg so to speak.

Please keep in mind the "which comes first issue here- "chicken or the egg scenario" in our case the chicken being the solution draft's, and now we are working "bass-ackwards" with razor focus now after the fact back on the requirements which was missed at the get-go.

The WG Charter does have verbiage that is inclusive of BIER in IPv6 and does use the word "native" even though that has caused confusion and we have eliminated it from the requirements draft  - excerpt below.

The problem statement is crystal clear that the challenge now is how and where to encode BIER header in an IPV6 environment.  Plain and simple.

Dear BIER WG,

We the authors welcome all WG participants on the ML to help collectively define & further define the conceptual models, as well as address any deficiencies with the requirements we have put together in the draft rev-7.  I would like to make it clear that none of us authors are married to any solution and we welcome all ideas and solutions.

We are all striving to keep an open mind thinking outside the box, so we don't box ourselves into any one solution, and are open to look at any and all options or solutions out there.

We all want to be successful in coming up with a BIER solution that supports SRv6 the "end all be all" replacement for MPLS.

Kind Regards,

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!VEgzCXOaKlsmXvBdIGei4pBwRixBrwdKLeLUi509_aX31LZk8u1wqP_ZpM1MhylX$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

On Fri, Sep 18, 2020 at 11:47 AM Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
Jingrong,

or

- Shep
(chairs)

Thanks
Jingrong

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 7, 2020 10:19 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: BIER/IPv6 Requirements and Solutions

Hello all!

Thanks!!

Alvaro.

===

345     4.1.1.  L2 Agnostic

In summary, the list of requirements presented is not clear or adequately justified.  It is not conducive to a WG discussion about the requirements themselves...much less about potential solutions.
_______________________________________________
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!VEgzCXOaKlsmXvBdIGei4pBwRixBrwdKLeLUi509_aX31LZk8u1wqP_ZpGzD5mHD$>

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!VEgzCXOaKlsmXvBdIGei4pBwRixBrwdKLeLUi509_aX31LZk8u1wqP_ZpM1MhylX$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 24 Sep 2020 07:44:17 -0700

The authors were ask to remove the comparison section. I'm asking you
again. I'll wait for the next rev to comment.

Thanks,
Greg

On Thu, Sep 24, 2020 at 2:44 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi Gyan,
>
>
>
> A small clarification – while the requirements draft -07 currently does
> have sections that briefly describe different models/solutions, we have
> avoided discussing which one satisfies which requirements intentionally (as
> the focus is on listing requirements).
>
>
>
> With that, I don’t think we’ve got a conclusion that “BIER-MPLS &
> SRv6 Service Provider core technology requiring an IPv6 data plane”.
>
>
>
> Jeffrey
>
>
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Thursday, September 24, 2020 1:40 AM
> *To:* Greg Shepherd <[email-masked]>
> *Cc:* Xiejingrong (Jingrong) <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]; Alvaro Retana <[email-masked]>
> *Subject:* Re: [Bier] BIER/IPv6 Requirements and Solutions
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Greg
>
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!VEgzCXOaKlsmXvBdIGei4pBwRixBrwdKLeLUi509_aX31LZk8u1wqP_ZpM1MhylX$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!VEgzCXOaKlsmXvBdIGei4pBwRixBrwdKLeLUi509_aX31LZk8u1wqP_ZpGzD5mHD$>
>
>
>
>
> --
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!VEgzCXOaKlsmXvBdIGei4pBwRixBrwdKLeLUi509_aX31LZk8u1wqP_ZpM1MhylX$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 24 Sep 2020 11:24:14 -0700

> our best foot forward with this rev 7.

Gyan, first, please switch off the SRv6 marketing trumpet rather than
focusing on the feedback WG/AD/chairs provided. Whatever you say here
presents your opinon on many things and your opinion only which may or may
not be wrong, fact being, neither is SRv6 cooked with many things like SRm6
in flight and some basic drafts still under serious contention.

I won't repeat all the technical/charter and other arguments that are well
documented in email threads and minutes and have been repeatedly
dismissed/unaddressed with the tenor from the authors largely matching your
email here.

Overall I'm agreeing with Greg's email that what should be done with this
draft to right the ship, i.e. unadopt it or build a much more
inclusive/diverse authors' list that is interested in working within the
IETF process. Or ultimately just ice it and start a new draft altogether.

thanks

-- tony

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 24 Sep 2020 15:22:01 -0400

On September 17, 2020 at 10:48:51 PM, Xiejingrong (Jingrong) wrote:

Jingrong:

Hi!

> direction is correctly followed and if your comments are addressed.

I'm replying because you continued this thread (and directed the
message to me), but I would have preferred a discussion inside the WG.

As Greg already mentioned, the requirements should provide enough
information to determine "what any proposed solution needs to address
that cannot be addressed with the available tools today".  In light of
my previous review, let's take a quick look at the mandatory
requirements:

[Line numbers from idnits.]

255	4.1.1.  Support various L2 link types

257	   The solution should support various kinds of L2 data link types.

Which are the mandatory types?  Ethernet, I guess.  I assume that
some, like maybe IEEE 802.15.4, may not be.

If the intent is to run BIER "through an IPv6 network underlay",
doesn't the requirement of multiple L2 link support fall on IPv6?

259	4.1.2.  Support BIER architecture

261	   The solution must support the BIER architecture.

263	   Supporting different multicast flow overlays, multiple sub-domains,
264	   multi-topologies, multiple sets, multiple Bit String Lengths, and
265	   deterministic ECMP are considered essential functions of BIER and
266	   need to be supported.

This is an obvious requirement.  Sure, the WG can discuss whether a
solution complies with the BIER architecture, but because we are in
the bier WG I would assume that is a given.

Are there specifics on how the sub-domains (for example) need to be
set up for an IPv6 network that may be different from an MPLS network?
 I’m just grasping at straws...

268	4.1.3.  Support deployment with Non-BFR routers

270	   The solution must support deployments with BIER-incapable routers.
271	   This is beneficial to the deployment of BIER, especially in early
272	   deployments when some routers do not support BIER forwarding but
273	   support IPv6 forwarding.

Support for non-BFR routers is already part of the architecture.

275	4.1.4.  Support OAM

277	   BIER OAM should be supported, either directly using existing methods,
278	   or by specifying a new method for the same functionality.  It may be
279	   considered essential as part of the BIER architecture in some cases.

As I mentioned before, there's no standard BIER OAM method to be
supported, or to build "a new method for the same functionality".

Assuming compliance with the BIER architecture, out of these mandatory
requirements I don't think I can identify one that would help the WG
decide whether a new solution is needed, or select between multiple of
them. :-(

Thanks!

Alvaro.

---

From: Michael McBride <[email-masked]>
Date: Fri, 25 Sep 2020 00:11:21 +0000

Hi Tony,

I moved section 3 to the appendix in the 08 version I just submitted. Please see MM below:

>Gyan, first, please switch off the SRv6 marketing trumpet rather than focusing on the feedback WG/AD/chairs provided. Whatever you say here presents your opinon on many things and your opinion only which may or may not be wrong, fact being, neither is SRv6 cooked with many things like SRm6 in flight and some basic drafts still under serious contention.

MM: Dismissing a technology viewpoint as marketing is not helpful. We should be encouraging ietf participation, not discouraging it, especially from operators.

>Overall I'm agreeing with Greg's email that what should be done with this draft to right the ship, i.e. unadopt it or build a much more inclusive/diverse authors' list that is interested in working within the IETF process. Or ultimately just ice it and start a new draft altogether.

MM: I think we are all well aware of the chairs viewpoint on this draft. The goal now is to see if the wg shares in that viewpoint. Here’s the list of authors:

M. McBride Futurewei
J. Xie, X. Geng, S. Dhanaraj Huawei
R. Asati Cisco
Y. Zhu China Telecom
G. Mishra Verizon Inc.
Z. Zhang Juniper

This is the most diverse authorship of any draft I’ve been involved with. We won’t be publishing the draft so we can add many more authors as needed. Feel free to join us and edit away.

mike

 --

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C2764f5f5ac504419677208d860b728de%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637365687069322372&sdata=cGZYQESGOKcJvwowUTfVFAcufJKJB%2B7JcTfACSrYT1k%3D&reserved=0>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Fri, 25 Sep 2020 03:08:59 +0000

Just one more comment: Any WG feedback is welcome. All the previous comments are carefully considered and discussed among authors[*]. If there is something new, raise it up with implementable operations and it will be addressed. (Unless I'm missing something, section 3 hasn’t been asked to be removed or even considered inappropriate until version 07 was published in my knowledge)

Xuesong

[*]Here are all the comments we have received from WG since IETF 108 (most recent comments not inluded). Here are some explanations about how we address/consider these comments in version 07.

1.      Comments from Greg Shepherd
Section 2 Problem Statement
-        “IPv6 unicast technologies can support multi-point transport” seems not clear
[New Version] This sentence has been removed

Section 3.2 Naive IPv6 Model
-  “BIER is integrated into the IPv6 data plane” is not precise, could be considered to modify as “BIER header integrated into the IPv6 header”
[New Version] Similar expressions are maintained in this version, including:
“   The second conceptual model is an Integrated Model that integrates
   BIER as part of the IPv6 data plane, making it a "Layer-3 BIER"
   approach.”
“In this model, BIER works as part of the IPv6 data plane.”
This has been discussed among the authors. If we take it narrowly, “IPv6 data plane” may mean to look up IP routing table and find the next hop, in which case, BIER could not be treated as part of it; while if we take it broadly, “IPv6 data plane” may include all the forwarding behavior happening in IPv6 layer including parsing extension headers, in which case, BIER could be treated as part of it.

2.      Comments from Sandy Zhang:
Section 2 problem statement
-        Not only non-BFR node scenario should be included
[New version] It has been covered in the new version by
“It may
   also be desirable to not use IPv6 encapsulation except when IPv6
   tunneling (native or GRE/UDP-like) is used to transport BIER packets
   over BIER-incapable routers.”

Section 3.1
-        There is no fragmentation or IPSEC executed in BFR
[New Version]
An example has been added in section 4.2.1 to clarify the case and fix the comments.

Section 3.2
-        Fast forwarding could not be supported if using IPv6 extension header
-        How to deal with the relationship with other extension header, e.g., fragmentation header
[New version]
This will be defined in the solution document rather than the requirement document.

3.      Comments from Jeffrey Zhang:
Section 2  Problem Statement -> Request to remove/modify the descriptions that may be considered biased:
-        Inter-domain is not model specific. Reference to individual draft should be removed.
[New version]
Descriptions about Inter-domain has been removed.
-        The descriptions of fragmentation is not reasonable because fragmentation/reassembly does not happen on each BFR when it is connected directly with another BFR.
[New version]
Descriptions about fragmentation in section 3 has been removed.
-        IPv6 native functions should not be requested by Layer2.5 tunneling, which could be executed in IPv6 layer.
[New version]
Descriptions about other IPv6 functions in section 3 have been removed.
Section 4.1.6  Simple Encapsulation-> Unclear requirement item
[New version]
This requirement has been removed.

4.      Comments from Alvaro Retana
Section 2
-        Problem Statement should be straight forward
[New version]
Problem Statement has been modified totally with help of Gyan and Jeffrey.

Section 3
-        Transport-Independent Model" is not in line with the layering model from rfc8279
[New version]
The layering of BIER defined in RFC8279 is not the same as it has been discussed in section 3, where layer 3/layer 2.5 means protocol layering of TCP/IP.
-        It seems that there is some Bias for native IPv6 Model
[New version]
Section 3.1.  Independent Model has been well modified by Jeffrey as the one of the main authors of the document of BIERin6.

Section 4
-        Three levels: required, recommended, and optional
-        Some mandatory requirements need no explanation, including: Support BIER architecture; Conform to existing IPv6 Spec; Support deployment with Non-BFR routers)
-        Some of the requirements are not clear, e.g., L2 Agnostic, Support Simple Encapsulation, Support Deployment Security
-        Some of the requirements are not included in RFC8279, e.g., Support inter-AS multicast deployment
[New version]
All the requirement items have been reorganized. Well known requirement is kept simple and optional requirement is justified with example.

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]]
Sent: Thursday, September 24, 2020 10:44 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Alvaro Retana <[email-masked]>
Subject: Re: [Bier] BIER/IPv6 Requirements and Solutions

The authors were ask to remove the comparison section. I'm asking you again. I'll wait for the next rev to comment.

Thanks,

Greg

On Thu, Sep 24, 2020 at 2:44 AM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>

> A small clarification – while the requirements draft -07 currently

> does have sections that briefly describe different models/solutions,

> we have avoided discussing which one satisfies which requirements

> intentionally (as the focus is on listing requirements).

> BIER-Ethernet, as it stands today has a MAJOR gap in being able to

> support

> *From:* Gyan Mishra <[email-masked]<mailto:[email-masked]>>

> *To:* Greg Shepherd <[email-masked]<mailto:[email-masked]>>

> *Cc:* Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>;

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>; Alvaro Retana <[email-masked]<mailto:[email-masked]>>

> With all do respect, the authors welcome the AD and Chairs criticism

> and any feedback, however in this particular case with your response,

> there seems to be a disconnect with the ML discussions we have had

> over the last several months.  Understandably, all of us here in the

> WG realize the criticality of the BIER in an IPv6 environment, and

> that BIER-MPLS & BIER-Ethernet, as it stands today has a MAJOR gap in

> being able to support

> SRv6 Service Provider core technology requiring an IPv6 data plane,

> which will be the end all be all replacement for MPLS.  It is critical

> that the BIER WG come up with a solution(s) that supports an IPv6 data

> plane for

> SRv6 support.  We all don't want BIER to die on the vine in a

> technology graveyard with ATM, Frame Relay and the likes.  We the

> authors are all in agreement and running fast after that goal and

> understand the AD & Chairs now emphasis on the requirements draft.  We

> are with you lock, stock and barrel.

> collaborated in a joint effort over a month timeframe with the authors

> of the BIER IPv6 Solutions draft “draft-zhang-bier-bierin6-07”,

> BIERin6, referred to as the Independent model , authors Jeffrey &

> Sandy to come up with a holistic solution where both conceptual models

> accurately addressed the problem statement as well as the requirements

> to support IPv6 for SRv6 support.  We wanted to make sure that we had

> complete parity between conceptual models and relationships to the

> problem statement and requirements list.  All authors from both

> solutions worked together to ensure we had all of our “i’s” dotted &

> “t’s” crossed so to speak, putting our best foot forward with this rev 7.

> BIERin6 Solution came out in October 2017.  It is only since January

> 2019 initial draft submission has the work to reverse engineer to come

> up with the Requirements draft started a “post mortem” so to speak

> after the Solutions had already been proposed.  To that end in

> IETF108, the requirements draft had positive feedback related to

> Section 3 conceptual framework for the two solutions proposed.  We are

> all at a loss in understanding your comments as to removal of section

> 3.  In order to create a requirements draft as part of any basic

> requirements analysis, you must have some idea or concept or inkling

> of a solutions framework to graft & glean the list of requirements which otherwise is not possible in my mind

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 25 Sep 2020 07:40:49 -0700

Xuesong,

Inline:

On Thu, Sep 24, 2020 at 8:09 PM Gengxuesong (Geng Xuesong) <
[email-masked]> wrote:

> Just one more comment: Any WG feedback is welcome. All the previous
> comments are carefully considered and discussed among authors[*]. If there
> is something new, raise it up with implementable operations and it will be
> addressed. (Unless I'm missing something, section 3 hasn’t been asked to be
> removed or even considered inappropriate until version 07 was published in
> my knowledge)
>

There was no 'solution comparison' section in rev 0. It appeared in rev1,
and at the end of the doc. Since then that section has been carefully
word-smithed to direct the conversation about the requirements themselves.
It was removed in rev 4 at the request of the WG. Then it reappeared in rev
6 - without any WG request - and promoted to the top of the document, no
longer hiding the authors intent of leading the conversation on
requirements. So yes, nobody asked to remove it since rev 4 since it was no
longer there. As soon as it reappeared, the authors were asked to remove
it. Nothing new here except the authors' increasing pressure to resist
input from the WG.

Please remove that section rev the draft. There is nothing more to discuss
until then.

Thanks,
- Chairs
(Shep)

> Xuesong
>
>
>
> [*]Here are all the comments we have received from WG since IETF 108 (most
> recent comments not inluded). Here are some explanations about how we
> address/consider these comments in version 07.
>
>
>
> -  “BIER is integrated into the IPv6 data plane” is not precise, could be
> considered to modify as “BIER header integrated into the IPv6 header”
>
> This has been discussed among the authors. If we take it narrowly, “IPv6
> data plane” may mean to look up IP routing table and find the next hop, in
> which case, BIER could not be treated as part of it; while if we take it
> broadly, “IPv6 data plane” may include all the forwarding behavior
> happening in IPv6 layer including parsing extension headers, in which case,
> BIER could be treated as part of it.
>
>
>
> -        The descriptions of fragmentation is not reasonable because
> fragmentation/reassembly does not happen on each BFR when it is connected
> directly with another BFR.
>
> [New version]
>
> -        IPv6 native functions should not be requested by Layer2.5
> tunneling, which could be executed in IPv6 layer.
>
> [New version]
>
> The layering of BIER defined in RFC8279 is not the same as it has been
> discussed in section 3, where layer 3/layer 2.5 means protocol layering of
> TCP/IP.
>
> Section 3.1.  Independent Model has been well modified by Jeffrey as the
> one of the main authors of the document of BIERin6.
>
>
>
> Section 4
>
> -        Some mandatory requirements need no explanation, including:
> Support BIER architecture; Conform to existing IPv6 Spec; Support
> deployment with Non-BFR routers)
>
> -        Some of the requirements are not clear, e.g., L2 Agnostic,
> Support Simple Encapsulation, Support Deployment Security
>
> All the requirement items have been reorganized. Well known requirement is
> kept simple and optional requirement is justified with example.
>
>
>
>
>
>
>
> Cc: Gyan Mishra <[email-masked]>; Xiejingrong (Jingrong) <
> [email-masked]>; [email-masked];
> [email-masked]; [email-masked]; Alvaro Retana <[email-masked]
> >

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 25 Sep 2020 13:08:54 -0400

Hi Greg

In-line

On Fri, Sep 25, 2020 at 10:41 AM Greg Shepherd <[email-masked]> wrote:

>> is something
>> new, raise it up with implementable operations and it will be addressed.
>> (Unless I'm missing something, section 3 hasn’t been asked to be removed or
>> even considered inappropriate until version 07 was published in my
>> knowledge)
>>
>

I just went through all the versions to see where section 3 is added or
omitted below:

Rev 0 - omitted
Rev 1 - omitted
Rev 2 and 3 - appears in 5.4 5.5 I think that is what you ar talking about
word smithing ..
Rev 4 omitted
Rev 5-7 - added back
Rev 8 - moved to appendix

Based on the above we will  remove section 3 from the appendix.

Since the solutions drafts themselves speak for the solutions in detail I
think we can focus strictly on the requirements in this draft as Greg, Tony
and Alvaro stated.

Greg -  I was not aware of the details history of what transpired early
this year with the few revisions prior to me joining as author.  I will
work with the team to right the ship remain steadfast on the requirements.

Thanks

Gyan

>>
>> Xuesong
>>
>>
>>
>>
>>
>> [*]Here are all the comments we have received from WG since IETF 108
>> (most recent comments not inluded). Here are some explanations about how we
>> address/consider
>>
>> these comments in version 07.
>>
>>
>>
>>
>>
>> which case,
>> BIER could not be treated as part of it; while if we take it broadly,
>> “IPv6 data plane” may include all the forwarding behavior happening in IPv6
>> layer including parsing extension headers, in which case, BIER could be
>> treated as part of it.
>>
>>
>>
>>
>>
>> directly with
>> another BFR.
>> deployment with Non-BFR
>> routers)
>> All the requirement items have been reorganized. Well known requirement
>> is kept simple and optional requirement is justified with example.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> [email-masked]; [email-masked]; Alvaro Retana <
>> [email-masked]>
>>
>>
>> > With that, I don’t think we’ve got a conclusion
>>
>> that “BIER-MPLS &
>>
>>
>>
>> [email-masked];
>>
>> [email-masked];
>>
>>
>>
>> > “draft-xie-bier-ipv6-encapsulation-08”,
>>
>> BIERv6, referred to as the
>>
>>
>> > “Integrated model”, authors myself, McBride,
>>
>> Xuesong & Jingrong
>>
>>
>> > of the BIER IPv6 Solutions draft
>>
>> “draft-zhang-bier-bierin6-07”,
>>
>>
>>
>> > solutions worked together to ensure we had all of our
>>
>> “i’s”
>>
>> dotted &
>>
>>
>> > “t’s”
>>
>> crossed so to speak, putting our best foot forward with this rev 7.
>>
>>
>> >
>>
>>
>> >
>>
>>
>> >
>>
>>
>> > I would like to point out that given the
>>
>> “Integrated model” BIERv6
>>
>>
>>
>> > Solutions initial draft came out in April 2018, and the
>>
>> “Independent model”
>>
>>
>> > up with the Requirements draft started a
>>
>> “post mortem” so to speak
>>
>>
>>
>> > of a solutions framework to graft & glean the list of requirements
>> which otherwise is not possible in my mind
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --

*Gyan Mishra*

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 25 Sep 2020 10:15:52 -0700

Thanks Gyan. I'll wait the new rev.

Cheers,
Greg
(Chairs)

On Fri, Sep 25, 2020 at 10:09 AM Gyan Mishra <[email-masked]> wrote:

>> Please remove that section rev the draft. There is nothing more to
>> discuss until then.
>>
>> Thanks,
>> - Chairs
>> (Shep)
>>
>>
>
>>> -  “BIER is integrated into the IPv6 data plane” is not precise, could
>>> be considered to modify as “BIER header integrated into the IPv6 header”
>>>
>>>
>>> Section 2  Problem Statement -> Request to remove/modify the
>>> descriptions that may be considered biased:
>>>
>>>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Sun, 27 Sep 2020 01:45:16 +0000

Hi Greg,

Thank you for pointing out your concern. There is no intension from authors to resist input from the WG, especially when it is fully clarified. We will update the document based on these comments.

Best
Xuesong

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Friday, September 25, 2020 10:41 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: [email-masked]; Gyan Mishra <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; Alvaro Retana <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Bier] BIER/IPv6 Requirements and Solutions

Xuesong,

Inline:

On Thu, Sep 24, 2020 at 8:09 PM Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>> wrote:
Just one more comment: Any WG feedback is welcome. All the previous comments are carefully considered and discussed among authors[*]. If there is something new, raise it up with implementable operations and it will be addressed. (Unless I'm missing something, section 3 hasn’t been asked to be removed or even considered inappropriate until version 07 was published in my knowledge)

There was no 'solution comparison' section in rev 0. It appeared in rev1, and at the end of the doc. Since then that section has been carefully word-smithed to direct the conversation about the requirements themselves. It was removed in rev 4 at the request of the WG. Then it reappeared in rev 6 - without any WG request - and promoted to the top of the document, no longer hiding the authors intent of leading the conversation on requirements. So yes, nobody asked to remove it since rev 4 since it was no longer there. As soon as it reappeared, the authors were asked to remove it. Nothing new here except the authors' increasing pressure to resist input from the WG.

Please remove that section rev the draft. There is nothing more to discuss until then.

Thanks,
- Chairs
(Shep)

Xuesong

Section 3.1

Section 3.2

Section 3

Section 4

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, September 24, 2020 10:44 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] BIER/IPv6 Requirements and Solutions

Thanks,

Greg