Re: [Bier] BIER/IPv6 Requirements and Solutions

[Greg Shepherd <[e-mail]>]

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 <[e-mail]>
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 &
> 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 <[e-mail]>
> *Sent:* Thursday, September 24, 2020 1:40 AM
> *To:* Greg Shepherd <[e-mail]>
> *Cc:* Xiejingrong (Jingrong) <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]; Alvaro Retana <[e-mail]>
> *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.
>
>
>
> 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,
>
>
>
> [image: 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 <[e-mail]> wrote:
>
> 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) <
> [e-mail]> 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:[e-mail]]
> Sent: Friday, August 7, 2020 10:19 PM
> To: [e-mail];
> [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]
> 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.
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!VEgzCXOaKlsmXvBdIGei4pBwRixBrwdKLeLUi509_aX31LZk8u1wqP_ZpGzD5mHD$>
>
>
>
>
> --
>
> [image: 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
>
>
>