Re: [Bier] BIER/IPv6 Requirements and Solutions

[Gyan Mishra <[e-mail]>]

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 <[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
>


-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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