Subject: [Bier] BIER/IPv6 Requirements and Solutions

From: Alvaro Retana <[email-masked]>
Date: Fri, 7 Aug 2020 07:18:37 -0700

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: Tianran Zhou <[email-masked]>
Date: Mon, 10 Aug 2020 04:24:42 +0000

Hi Alvaro and the WG,

I jumped in this mailing list a month or so.
I would like to share my points after this mail. 
Please see inline.

Best,
Tianran

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Alvaro Retana
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] 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.

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.

ZTR> I do not agree with you. I think the requirement is straight forward and easy to understand. I even think there is no need for the requirement document for a consensus. Your comment here is very high level without any guidance. Could you please point out, what justification need to reach consensus?

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.

ZTR> I agree with your point here. The document does not need to discuss about the charter. So can I say the Chairs and anybody should not block this work with the interpretation of current charter?

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.

ZTR> As in your comments below " Some of the mandatory requirements listed are obvious and probably don't need even to be mentioned. " , that's also my observation. 
Again, the requirement (not mean this document) is straight forward and easy to understand. I think we can go straight to the solution. Discussion on the details of this document, especially on which one is mandatory, which one is optional, is waste of time. 

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.

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

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

345	4.1.1.  L2 Agnostic

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?  :-(

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
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 10 Aug 2020 08:44:25 -0700

On August 10, 2020 at 12:24:49 AM, Tianran Zhou  wrote:

Tianran:

Hi!  How are you?

...
> 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.
>
> ZTR> I do not agree with you. I think the requirement is straight forward
> and easy to understand. I even think there is no need for the requirement
> document for a consensus. Your comment here is very high level without any
> guidance. Could you please point out, what justification need to reach
> consensus?

[I'm assuming you're talking about the general need to run bier over
IPv6 when you characterize the requirement as "straight forward and
easy to understand."]

Given that this potential work item made it into the Charter, I also
assume that the need to run bier over an IPv6 dataplane is
straightforward.  On the other hand, the decision of which of the
multiple (and different) solutions to pursue (one, many, none ?) is
what doesn't have consensus.  I hope that my notes on the document
itself were more specific.

I will leave the discussion as to whether a requirements document is
necessary to the WG.

> 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.
>
> ZTR> I agree with your point here. The document does not need to discuss
> about the charter. So can I say the Chairs and anybody should not block
> this work with the interpretation of current charter?

The point I tried to make above is about not blindly allowing or
blocking something just because it is in the Charter, or not.  For
both scenarios (written in the Charter or not) the important parts are
discussion and consensus.  IOW, nothing should progress if there is no
WG consensus on it.

Alvaro.

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 11 Aug 2020 02:08:05 +0000

Hi Alvaro,

Thanks for your reply.
Please see in line.

Best,
Tianran

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]] 
Sent: Monday, August 10, 2020 11:44 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Tianran Zhou <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Bier] BIER/IPv6 Requirements and Solutions

Tianran:

Hi!  How are you?

...
> requirements, the text should include a clear justification for the WG to reach a consensus.
> ZTR> I do not agree with you. I think the requirement is straight 
> ZTR> forward
> and easy to understand. I even think there is no need for the 
> requirement document for a consensus. Your comment here is very high 
> level without any guidance. Could you please point out, what 
> justification need to reach consensus?

[I'm assuming you're talking about the general need to run bier over
IPv6 when you characterize the requirement as "straight forward and easy to understand."]

Given that this potential work item made it into the Charter, I also assume that the need to run bier over an IPv6 dataplane is straightforward.  On the other hand, the decision of which of the multiple (and different) solutions to pursue (one, many, none ?) is what doesn't have consensus.  I hope that my notes on the document itself were more specific.

ZTR> Great! I think we can now be crystal clear about the IPv6 requirement. I think the working group does not need to circulate the requirement discussion on whether we need IPv6 or not.
Then, I think the two solutions currently discussed in working group do not conflict. Both can find their own scenario and target network. Typically one is in IP layer, the other is above the IP layer (transport?).

I will leave the discussion as to whether a requirements document is necessary to the WG.

ZTR> The WG could work on the requirement if there are interests. But I do not think this document is must. As you also mentioned, you do not expect it to be published as RFC.
So I think each encapsulation solution can justify themselves not depending on this requirement document. In other words, the requirement document should not block or delay the encapsulation solutions. 

> must not be used as justification for doing work in the absence of discussion and consensus.
>
> ZTR> I agree with your point here. The document does not need to 
> ZTR> discuss
> about the charter. So can I say the Chairs and anybody should not 
> block this work with the interpretation of current charter?

The point I tried to make above is about not blindly allowing or blocking something just because it is in the Charter, or not.  For both scenarios (written in the Charter or not) the important parts are discussion and consensus.  IOW, nothing should progress if there is no WG consensus on it.

ZTR> The consensus should be based on reasonable technical points. Otherwise I can simply object any proposal. The chairs should remind this and guide the right discussion. But, in this working group, a lot of non-technical points in my perspective.
I do not think the discussion should run like this.

Alvaro.