Re: [Bier] In reply to the formal complaints

[Tony Przygienda <[e-mail]>]

Keeping it terse to not make it another 100 mails rehash of endless threads
along the same lines we had over last 1.5 years or so. \

First, I advise the usual suspects here to not start to steer the thread
(which should concern itself with any relevant technical angle & input if
there is some to be had) again towards their technical content free
personal beliefs, opinions, preferences, feelings and borderline personal
attacks and gripes about the process and WG. Enough of that has been had on
lists and WG chats to the point of extending formal complaints already ...

Second, given Robin is a newcomer to discussion here I extend very terse
answer since the arguments can be found in archives and according complaint
communications. So I only answer some summary points

As first observation, I think it is time to point out to the authors & your
company proponents of BIERv6 that there is NO BIERv6. BIER does have a
version field under governance of an IETF registry and what you talking
about in your email is clearly "BIER encoded in SRv6" so we would
appreciate enormously if you'll call this work from now on something along
the lines of "SRv6 BIER encoding" and hence we will avoid confusion by
folks trying to understand the technical content of this work and think
it's some kind of new BIER version or BIER tunneling.

Point 2: it seems that your feeling goes towards "layering is bad, flat is
good, IPv6 L3 encoding can replace everything with enough option hacks and
redefining addresses to mean other things". This is purely a preference
whereas the world's internet has been built on a layered, distributed
networking stack providing an address and layer based security architecture
without controllers. Moreover, attempts to build L3 multicast
replication/tunneling/signalling in one blob were tried and if they would
have been successful BIER WG would not be even chartered. Further I observe
that lots of things you assume as chartered/given/solved are quite
ambitious such as _multicast_ OAM in SRv6 and multicast fragmentation while
ignoring things like RFC8085 (or maybe assumption is that SRv6 will add
multicast MTU discovery as well) and liberally adding things you like to
RFC8279. Following this philosophy, ethernet OAM is probably on its way to
be replaced as well ;-)

Point 3: AFAIS to implement BIERin6 on linux it seems all is needed is a
raw v6 socket with next protocol BIER without any kernel modules or
extensions so I read your assertion that SRv6 encoded BIER is somehow
superior on host purely as personal belief.

Ultimately, I don't seem to see any technical issues summarized during the
format complaint  addressed in detail in your email. As example, I still
don't see any use case "SRv6 encapsed BIER" solves that BIERin6 doesn't
simply solve which is one of the key consideration while I read a lot of
assumptions and preferences about what BIER should be in eyes of SRv6
which, while acknowledged, do not seem to contribute anything substantially
new to the long drawn out discussion or the technical arguments extended
while we closed the process of considering the draft's merits to fit into
WG as work item

thanks

--- tony




On Thu, Jun 17, 2021 at 6:51 PM Lizhenbin <[e-mail]> wrote:

> Hi Folks,
>
> Through the discussion, we can learn more about the conflict of the design
> consideration between BIERin6 and BIERv6. In my opinion, it is not
> appropriate to consider BIERv6 and BIERin6 as the competitive solutions
> thought there is some overlap. The relationship between BIERv6 and BIERin6
> is similar as that between SR-MPLS over IP and SRv6 which can be co-exist
> for the different scenarios.
>
> - For BIERin6, it tries to keep the BIER as an independent layer and takes
> the IPv6 as the transport tunnel. (In SR-MPLS over IP, the MPLS is the
> independent layer from the IP)
>
> - For BIERv6, it takes the native IPv6 design like SRv6.
>
>
>
> According to the design, there can be different applications scenarios:
>
> 1. For MVPN, with BIERin6, the MPLS label can be allocation for the MVPN
> instance and can be carried in the BIER layer. BIERv6 will not support the
> usecase. As the native IPv6 design, it will always use the IPv6 segment to
> indicate the MVPN instance.
>
> 2. With BIERv6, it is easy to support the advanced features such as the
> fragment and IPSEC functionalities combining with the existing IPv6
> extension headers. On the contrary, in order to support these features in
> the BIERin6 solutions which take the BIER as an independent layer, Jeffery
> proposed the draft to define the general transport header for the BIER
> layer to support the fragment and IPSec features. But I do not think it is
> enough. Now the new functionalities such as network slicing, IOAM and other
> new functionalities have been proposed. According to the solutions of
> BIERin6, it is necessary to go on define the extension headers in the BIER
> layer. If so, for the BIERin6, the fragment/IPSec/network slicing/IOAM
> headers/options can exist in both the IPv6 extension headers and the BIER
> layer. We also need the specification to define how to process the
> co-existence of the same functionalities in IPv6 layer and BIER layer. In
> my opinion, this is not reasonable and necessary.
>
> I am not sure how ambitious the BIER WG to keep the BIER as the
> independent layer. If it is ambitious enough, there can be the
> functionalities including fragment, IPSec, IOAM network slicing, APN, etc.
> to be developed in the BIER layer. At the same time, the similar
> functionalities are being developed in the MPLS data plane and the IPv6
> data plane. So we will encounter the following challenges:
>
> 1) With BIERin6, it will be the following options:
>
> Option 1: IPv6 basic header + BIER layer (including fragment, IPSec, IOAM
> network slicing, APN, etc.)
>
> Option 2: IPv6 header (including fragment, IPSec, IOAM network slicing,
> APN, etc. ) + BIER layer (including fragment, IPSec, IOAM network slicing,
> APN, etc.)
>
> No matter whatever options, the doubt will be arised why duplicate
> functionalites are developed in both the IPv6 layer and the BIER layer.
>
> 2) For BIER in MPLS, it seems the BIER header is only encapsulated in the
> MPLS encapsulation as other functionalities instead of maintaining an
> independent layer. I am not sure about the conclustion. If it is yes, it
> seems conflicted with the design concept claimed by BIERin6 to keep BIER as
> the independent layer. If it is not, BIER will be kept as the independent
> layer and there will be the following case:
>
> MPLS layer (including fragment, IPSec, IOAM network slicing, APN, etc.) +
> BIER layer (including fragment, IPSec, IOAM network slicing, APN, etc.)
>
> The doubt will be arised again why duplicate functionalites are developed
> in both the MPLS layer and the BIER layer.
>
> When the BIER WG was setup, it cannot be expected later there would be
> many new funcationalities to be developed. I do not think it is appropriate
> to be strict with the layered architecture of BIER. And the scope of the
> BIERin6 solution should also be controlled. Though it seems possible to
> support the above new functionalities with the layered architecture
> insisted by the BIERin6, it may cause a mess of the architecture design.
> But with BIERv6, the advanced functionalities can be supported easily.
>
> This is similar as the relation between SR-MPLS over UDP and SRv6. SR-MPLS
> over IP is claimed as “a poor man solution” and the scope is maily confine
> to traverse the IP domain. On the contrary, in the solution of SRv6, the
> advanced features are supported in the IPv6 layer.
>
> 3. Moreover, since the BIERv6 takes the native IPv6 design, there is the
> possibility that the multicast funcation can be directly initiated in the
> host side, That is, the BIERv6 can be deployed host-to-host traversing the
> network domain. This is like the SRv6 to introduce some extention of socket
> which has been implemented in the Linux. For BIERin6, I do not think there
> is the possibility.
>
>
>
> The above analysis can be summarized as follows:
>
> 1. BIERin6 can also support MPLS-based MVPN while BIERv6 will not support
> the functionality.
>
> 2. For the series of functionalities such as the fragment, IPSec, network
> slicing, IOAM, APN, etc. which is being developed in the MPLS layer and
> IPv6 layer, even if there is the possibility to support these
> functionalities in the BIER layer which is insisted by the BIERin6, it may
> caust the mess in the architecute design involving the MPLS/IPv6/BIER
> layer. I suggest the advanced functionalities should be implemented
> directly in the IPv6 layer like BIERv6 or the MPLS layer.
>
> 3. For the future possible host-to-host deployment, BIERv6 should take it
> rather than BIERin6.
>
>
>
> Like the co-existence of SR-MPLS over UDP and SRv6, there should be the
> co-eixstence BIERin6 and BIERv6 for the different scenarios even if there
> is the overlap. And there should not be the mess in the BIER WG. If it is
> insisted that the layered architecture and the encoding of the BIER header
> should not be changed (for BIERv6, some fields of the BIER header are truly
> unnecessary) in the BIER WG, since the BIERv6 adopts the same design
> concept as the SRv6, the work can be done in the SPRING WG (in fact the
> END.BIER can also be seen as a new flavor of the END in SRv6). Or like the
> TREE SID, the work can be done in the PIM WG where the multicast source
> routing can be explored together.
>
>
>
>
>
> Best Regards,
>
> Robin
>
>
>
>
>
>
>
>
>
> *From:* BIER [mailto:[e-mail]] *On Behalf Of *Greg Shepherd
> *Sent:* Thursday, June 17, 2021 1:08 PM
> *To:* m00759202 <[e-mail]>
> *Cc:* Xiejingrong (Jingrong) <[e-mail]>; [e-mail];
> Martin Vigoureux <[e-mail]>
> *Subject:* Re: [Bier] In reply to the formal complaints
>
>
>
> Inline:
>
>
>
> On Wed, Jun 16, 2021 at 5:47 PM Michael McBride <[e-mail]>
> wrote:
>
> Howdy,
>
> Le 2021-06-11 à 13:40, Xiejingrong (Jingrong) a écrit :
> > Dear Martin,
> >
> > We've responded to the summary from chairs on that thread. I think it
> reflects the key technical differences between us and the chairs.
> >>From chairs' point of view, BIERv6 violates BIER architecture, which is
> L2 in nature and should not be IPv6/SRv6 dependent.
> >>From our point of view, BIERv6 does not violate BIER architecture, which
> should be interpreted by RFC8279 text instead of other informal
> interpretation.
>
> >it appears to me that this is the discussion the WG needs to have and
> reach consensus on.
>
> My take from the chairs summary is that they believe BIERv6 is simply
> unnecessary, not that it violates the bier architecture.
>
>
>
> GS - Correct
>
>
>
> There are many of us who believe using EH for the bitstring is a great use
> of IPv6 with bier.
>
>
>
> GS - "Great use" is not a valid use-case. The WG has been asking the
> authors for years what the compelling use case is to motivate creating
> layer dependencies and we are still waiting.
>
>
>
> This was presented in 6man with positive feedback.
>
>
>
> GS - No, it was presented in 6man and the authors were told 6man had no
> issues with it from a v6 perspective but that the work needed to work
> through the BIER WG for all BIER issues. And the WG is rather exhausted at
> having to repeatedly address the same miss-represetned issues, miss-quoted
> members of other lists, and having our questions ignored. You are
> essentially DOS-ing the WG process rather than listening and collaborating.
> It's clear you are unwilling to work collaboratively within the group.
> We've tried.
>
>
>
> Perhaps the time has come to propose this work in an IPv6 EH friendly WG?
>
>
>
> GS - I trust you understand how the standards process works. Good luck.
>
>
>
> Greg
>
>
>
> mike
>
> >
> > For the detailed technical points in the BIERv6 solution, we think they
> have been checked carefully in BIER WG and other WGs for long time, and
> have been proven by implementation and test.
> > Also there are solid requirements from industry to have well-adapted
> BIER solution in IPv6/SRv6 network.
> >
> > We seek for your guidance to move our work forward in IETF. We would
> like to propose two options about what should be done in the next step:
> > 1) Consider to adopt BIERv6 in BIER WG, if BIERv6 complies with BIER
> architecture.
> > 2) Move BIERv6 work to other WG, e.g., PIM or SPRING, if BIERv6 does not
> comply with BIER architecture.
> >
> > Thank you very much for your help.
> >
> > Jingrong
> >
> > -----Original Message-----
> > From: BIER [mailto:[e-mail]] On Behalf Of Martin
> > Vigoureux
> > Sent: Monday, May 31, 2021 9:29 PM
> > To: [e-mail]
> > Subject: [Bier] In reply to the formal complaints
> >
> > WG
> >
> > First, I'd like to apologize for the time this has taken.
> >
> > I have reviewed the two formal complaints that were sent early March,
> and I have also reviewed most of the e-mails that were sent on the bier
> mailing list for the past 12 months or so, relating to BIER and IPv6.
> >
> > I will not individually discuss the various points raised, rather I will
> make a general statement.
> >
> > It is my opinion that a certain number of points are not critical (in
> the sense of not needing an AD to step-in) and some typically happen
> sometimes as part of the life cycle of WGs. Yet, I do recognize that some
> points are more problematic than others.
> > Further, it is my opinion that the points listed may arise from a
> variety of intentions and as such it is hazardous to associate them with a
> particular one.
> > It is however my opinion that the multiplicity of concerns is, in
> itself, a concern.
> > I have talked with the chairs. They do recognize that, at some
> occasions, their communication was not the most effective one, and I trust
> they will pay attention to that in the future.
> >
> > About the adoption poll on draft-zhang-bier-bierin6. Although the way
> this was handled raised some concerns, I'd like to remind that an adoption
> poll is not formally part of our processes, even if it is common practice,
> and in fact it only marks the start of the WG discussion. As such, I have
> little arguments to go back on this.
> >
> > The last part is about the progress of a so-called BIER v6 solution.
> > Here, I have asked the chairs to establish a summary of the discussions
> regarding that type of solution in general and regarding the specific
> document which proposes a solution. They should publish it some time after
> this e-mail.
> >
> > Following that, it is my expectation that the WG has a fair and open
> discussion, ideally focussing on the general aspects, and then concludes on
> the way forward.
> >
> >
> > Martin
> >
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmmcbride%40fut
> > urewei.com%7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a
> > 1d5591fedc%7C1%7C0%7C637592689222267034%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
> > p;sdata=ng78EEFJ0jNyOSdkvfv4Ic6xB3%2FpZkfY66Q%2BWdGZfIk%3D&amp;reserve
> > d=0
> >
>
> _______________________________________________
> BIER mailing list
> [e-mail]
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637592689222277027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dcV1PufJOI0NEKjONjsDIKK3Ib7%2BBF7xiHasDrnGTQs%3D&amp;reserved=0
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>