Subject: [Bier] proposed BIER charter

From: Alia Atlas <[email-masked]>
Date: Wed, 11 Feb 2015 15:44:25 -0500

I have been working on getting a charter together for BIER with the intent
of pushing for it to be chartered before the Dallas IETF.  This has not yet
gone through IESG review and it may have some aspects updated.

Please send comments here.

The charter can be found at
http://datatracker.ietf.org/doc/charter-ietf-bier/
and is included below as well.

WG Chairs:
  Greg Shepherd  <[email-masked]>
  Tony Przygienda <[email-masked]>

In conventional IP multicast forwarding, the packets of a given
multicast "flow" are forwarded along a tree that has been constructed
for the specific purpose of carrying that flow.  This requires transit
nodes to maintain state on a per-flow basis, and requires the transit
nodes to participate in multicast-specific tree building protocols.
The flow to which a packet belongs is determined by its IP source and
destination address fields.

BIER (Bit Index Explicit Replication) is an alternative method of
multicast forwarding.  It does not require any multicast-specific
trees, and hence does not require any multicast-specific tree building
protocols.  Within a given "BIER domain", an ingress node encapsulates
a multicast data packet in a "BIER header".  The BIER header
identifies the packet's egress nodes in that domain.  Each possible
egress node is represented by a a single bit within a bitstring; to
send a packet to a particular set of egress nodes, the ingress node
sets the bits for each of those egress nodes, and clears the other
bits in the bistring.  Each packet can then be forwarded along the
unicast shortest path tree from the ingress node to the egress nodes.
Thus there are no per-flow forwarding entries.

Due to the particular sensitivity of adding new significant
functionality into the data-plane at high link speeds, the BIER work
will progress as Experimental.  As described in item (9) below, the
work may become Standards Track once there is sufficient experience
with the benefits and downsides of the technology.

BIER is initially chartered to do experimental work on this new
multicast forwarding mechanism as follows:

   1) BIER architecture: The WG will publish an architecture, based
   upon draft-wijnands-bier-architecture-04.  It will include the
   normative algorithm for how BIER packet forwarding is done.  It
   will specify the information that is required by a BIER header to
   support BIER forwarding.

   2) BIER encapsulation: The working group should assume that the
   technology will need to be embedded in the data plane and operate
   at the highest packet line speeds.  The WG will publish a document
   defining an MPLS-based encapsulation based upon
   draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need
   to have a high-quality and stable RFC for a new data-plane
   encapsulation, the MPLS-based encapsulation draft shall wait after
   WGLC and not progress to IETF Last Call until there are two
   independent interoperable implementations.

   As a secondary focus, the WG may also work on one non-MPLS
   data-plane encapsulation.  This draft also shall wait after WGLC
   and not progress to IETF Last Call until there are two independent
   interoperable implementations.  This draft must focus on and
   include the following details:

       a) What is the applicability of the encapsulation and for which
       use-cases is this encapsulation required?

       b) Does this proposed encapsulation imply any changes to the
       MPLS-based encapsulation?

       c) What design choices have been made for the encapsulation
       type and the included fields.

       d) The proposed encapsulation with considerations given to at
       least OAM, Class of Service, security, fragmentation, TTL.

   3) Transition Mechanisms: The WG will describe how BIER can be
   partially deployed and still provide useful functionality.  A
   minimum of the necessary mechanisms to support incremental
   deployment and/or managing different BIER mask-length compatibility
   may be defined.  Each such mechanism must include an applicability
   statement to differentiate its necessity from other proposed
   mechanisms.

   4) Applicability Statements: The WG will work on a document
   describing how BIER can be applied to multicast L3VPN and to EVPN.
   This draft will describe what mechanism is used to communicate the
   group membership between the ingress router and the egress routers,
   what scalability considerations may arise, and any deployment
   considerations.

   5) Use Case: The WG may produce one use-case document that clearly
   articulates the potential benefits of BIER for different use-cases.
   This would be based upon draft-kumar-bier-use-cases-01.

   6) OAM: The WG will describe how OAM will work in a BIER domain and
   what simplifications BIER offers for managing the multicast
   traffic.  A strong preference will be given to extensions to
   existing protocols.

   7) Management models: The WG may work on YANG models and, if needed,
   MIB modules to support common manageability.

   8) IGP extensions.  When a BIER domain falls within a "link state IGP""
   network, the information needed to set up the BIER forwarding tables
   (e.g., the mapping between a given bit position and a given egress
   router) may be carried in the link state advertisements of the IGP.  The
   link state advertisments may also carry other information related to
   forwarding (e.g., the IGP may support multiple topologies, in which case
   it may be necessary to advertise which topologies are to be used for BIER
   forwarding).  Any necessary extensions to the IGP will be specified by
   the WG, in cooperation with the ISIS and OSPF WGs.

   9) Deployment Experience: Once there is deployment experience, the
   WG will produce a document describing the benefits, problems, and
   trade-offs for using BIER instead of traditional multicast
   forwarding mechanisms.  Ideally, this should also contain an
   analysis of the impact and benefit of the new BIER data-plane to
   the overall Internet architecture.  This document is intended to be
   used to evaluate whether to recharter BIER to produce Standards
   Track RFCs.

The BIER working group will coordinate with several different working
groups and must include the relevant other working groups during
working group last call on the relevant drafts.  BIER will coordinate
with MPLS on the MPLS-based encapsulation and associated MPLS-based
OAM mechanisms.  BIER will coordinate with ISIS and OSPF on extensions
to flood BIER-related information.  BIER will coordinate with BESS and
IDR on the applicability of existing BGP-based mechanisms for
providing multicast group membership information.

Regards,
Alia

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Feb 2015 03:20:38 +0000

Hi all,

I have a comment with regard to the BIER encapsulation. There were some discussions about the comparison between the MPLS-based BIER encapsulation and the non-MPLS-based BIER encapsulation previously. However, it’s till questionable whether the MPLS-based option is better than the non-MPLS-based option indeed. IMHO, the BIER layer is exactly a totally new NETWORK LAYER and therefore the BIER header is better to be designed as a complete network layer header from the beginning, rather than coupling it with an MPLS label so as to be capable of acting as a complete network layer header, which is specially meaningful in the non-MPLS network environments. Therefore, it seems more reasonable to allow the WG to work on the MPLS-based and non-MPLS-based encapsulation options concurrently and then to allow the WG or the market to make a choice between them latter, rather than picking one hastily without deeply investigating the pros and cons of each option. After all, we are designing a totally new NETWORK LAYER which is intended to provide stateless multicast service, rather than another new application of the MPLS technology.

Just my two cents.

Best regards,
Xiaohu

From: BIER [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Thursday, February 12, 2015 4:44 AM
To: [email-masked]
Cc: Adrian Farrel; Alvaro Retana
Subject: [Bier] proposed BIER charter

I have been working on getting a charter together for BIER with the intent of pushing for it to be chartered before the Dallas IETF.  This has not yet gone through IESG review and it may have some aspects updated.

The charter can be found at http://datatracker.ietf.org/doc/charter-ietf-bier/
and is included below as well.

WG Chairs:
  Greg Shepherd  <[email-masked]<mailto:[email-masked]>>
  Tony Przygienda <[email-masked]<mailto:[email-masked]>>

Regards,
Alia

---

From: Antoni Przygienda <[email-masked]>
Date: Thu, 12 Feb 2015 06:26:34 +0000

<hat type=”wg chair”>

IMHO, the BIER layer is exactly a totally new NETWORK LAYER
[Tony said] Xuxiaohu, that all depends how IP centric one sees it. It can be considered layer 2.5 as well given it doesn’t even have to carry IP frames.
and therefore the BIER header is better to be designed as a complete network layer header from the beginning, rather than coupling it with an MPLS label so as to be capable of acting as a complete network layer header, which is specially meaningful in the non-MPLS network environments. Therefore, it seems more reasonable to allow the WG to work on the MPLS-based and non-MPLS-based encapsulation options concurrently
[Tony said] I do NOT see anywhere in the charter that both CANNOT be worked on concurrently. Additional thought has been put into specifying WHAT a generic encoding draft needs to provide for it to be high quality and I think there is enough work to be done there. MPLS is simply the most pragmatic choice of a long mature L2.5 technology that provably solves many large-scale deployment problems.

</hat>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Feb 2015 09:28:28 +0000

Hi Tony,

Thanks a lot for your response. If the WG is intended to work on both MPLS-based and non-MPLS-based BIER encapsulation schemes concurrently, I would suggest making the following change to the BIER encapsulation related text:

OLD:

       d) The proposed encapsulation with considerations given to at
       least OAM, Class of Service, security, fragmentation, TTL.
NEW:
2) BIER encapsulation: The working group should assume that the
   technology will need to be embedded in the data plane and operate
   at the highest packet line speeds.  The WG will work on both MPLS-based
and non-MPLS-based BIER encapsulation schemes and publish the corresponding documents.
Due to the critical need to have a high-quality and stable RFC for a new data-plane
   encapsulation, the BIER encapsulation draft shall wait after
   WGLC and not progress to IETF Last Call until there are two
   independent interoperable implementations.

Best regards,
Xiaohu

From: Antoni Przygienda [mailto:[email-masked]]
Sent: Thursday, February 12, 2015 2:27 PM
To: Xuxiaohu; [email-masked]
Subject: RE: [Bier] proposed BIER charter

<hat type=”wg chair”>

</hat>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Feb 2015 13:44:47 +0000

Alia

I think that you are crossing far too many bridges before you get to them
in terms of you expectation of where BIER will be deployed and how
it will be implemented.

The charter should not include such specific assumptions, particularly
given the fast moving changes that are happening in our industry
especially in the area of packet forwarding design.

I have not seen such assumptions in other charters and I don't think
that they have a place in this one.

In terms of choice of document stream (experimental vs PS),
that is a decision that can be taken at the time of publication
when more information will be available in terms of potential
market take-up, expected/actual deployment scenarios,
breadth of implementation and implementation experience.

Whilst this technology may be deployed in the Internet core,
it my also be deployed at the edge where a much lower threshold
is applicable.

I fear that by introducing these caveats the IETF is entrenching the
perception that it slows technology down rather than embracing
and encouraging innovation.

I would therefore suggest removing the text on implementation
styles and document stream constraints.

- Stewart

On 11/02/2015 20:44, Alia Atlas wrote:
> I have been working on getting a charter together for BIER with the 
> intent of pushing for it to be chartered before the Dallas IETF.  This 
> has not yet gone through IESG review and it may have some aspects 
> updated.
>
>   Greg Shepherd  <[email-masked] <mailto:[email-masked]>>
>   Tony Przygienda <[email-masked] <mailto:[email-masked]>>
>
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Feb 2015 09:50:42 -0500

Xiaohu,

I certainly understand that you are very interested in working on a generic
encapsulation for BIER.  I do think this may be useful work.  The MPLS
encapsulation work is further along and has significant benefits in terms
of not needing to revisit a number of issues that MPLS already handles.

Your proposed changes basically eliminate any indication of what needs to
be considered in the generic encapsulation, without any reasoning, and
pushes for it to be considered as an equal focus with the MPLS
encapsulation.  I am already concerned that there's a lot of work for bier
to get through.

Do you think that the requirements on the generic encapsulation need
refining and why?

Regards,
Alia

On Thu, Feb 12, 2015 at 4:28 AM, Xuxiaohu <[email-masked]> wrote:

>  Hi Tony,
>
>
>
> Thanks a lot for your response. If the WG is intended to work on both
> MPLS-based and non-MPLS-based BIER encapsulation schemes concurrently, I
> would suggest making the following change to the BIER encapsulation related
> text:
>
>
>
> OLD:
>
> *From:* Antoni Przygienda [mailto:[email-masked]]
> *Sent:* Thursday, February 12, 2015 2:27 PM
> *To:* Xuxiaohu; [email-masked]
> *Subject:* RE: [Bier] proposed BIER charter
>
>
>
> <hat type=”wg chair”>
>
>
>
> *[Tony said] *Xuxiaohu, *that all depends how IP centric one sees it. It
> can be considered layer 2.5 as well given it doesn’t even have to carry IP
> frames. *
>
> and therefore the BIER header is better to be designed as a complete
> network layer header from the beginning, rather than coupling it with an
> MPLS label so as to be capable of acting as a complete network layer
> header, which is specially meaningful in the non-MPLS network environments.
> Therefore, it seems more reasonable to allow the WG to work on the
> MPLS-based and non-MPLS-based encapsulation options concurrently
>
> *[Tony said] I do NOT see anywhere in the charter that both CANNOT be
> worked on concurrently. Additional thought has been put into specifying
> WHAT a generic encoding draft needs to provide for it to be high quality
> and I think there is enough work to be done there. MPLS is simply the most
> pragmatic choice of a long mature L2.5 technology that provably solves many
> large-scale deployment problems. *
>
>
>
> </hat>
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Feb 2015 10:13:32 -0500

Stewart,

I certainly appreciate your taking the time to provide feedback.  I
understand that you
are excited by this technology and have urged that innovation needs time
and space
to be worked on before being evaluated by the harsh realities of the
marketplace and
interest in deployments.

> in terms of you expectation of where BIER will be deployed and how

I did read the use-cases and understand the primary motivation is for MVPN
and EVPN which are deployed in the backbone of SP networks that operate at
high speeds.  Even in data-centers, use of 10G links is common.

> especially in the area of packet forwarding design.

What specifically are you objecting to?

> that they have a place in this one.

What specific assumption are you objecting to and what reasoning do you have
beyond historical?

> breadth of implementation and implementation experience.

At this time, a sufficiently compelling case has not been made to convince
that
PS is anywhere near appropriate for this change of adding a completely new
forwarding
algorithm and a fourth  encapsulation to go with IPv4, IPv6, and MPLS to
the Internet
architecture for the next 15+ years.

It is true that if that changes between now and when drafts are ready to
progress, that can
be revisited.

There are WGs that have been chartered to do experimental work in the
past.  I understand
that it is disappointing that there wasn't a strong case for more than
experimental at this time.

I have been extremely clear since the last IETF that I was only considering
Experimental for
the WG for the initial chartering.

> it my also be deployed at the edge where a much lower threshold

The technology needs to work in both locations - given the use-cases.  What
specifically are
you objecting to?

> and encouraging innovation.

By creating a WG for open collaboration and defining an ambitious new
forwarding technology,
the IETF is not embracing and encouraging innovation?  I suppose it's all
in the eye of the
beholder - but to me it feels like "give an inch and get pushed for a
mile".

> styles and document stream constraints.

IF the encapsulations are specified in a way that two independent
interoperable implementations
are not available, it both increases the risk that we might end up with two
different versions - one
Experimental and another through bitter experience that is PS later - and
is a poor indication of
the lack of industry support and interest in the technology and its use.

Regards,
Alia

> BIER mailing [email-masked]://www.ietf.org/mailman/listinfo/bier
>
>
>
> --

---

From: <[email-masked]>
Date: Thu, 12 Feb 2015 23:20:11 +0000

Alia,

I have been engaged with BIER technology for the last year and a half from its inception. It come along way and it was not driven just based on excitement. This work is backed up by commitment from major vendors and multiple operators. I have discussed BIER on multiple occasions with other operators, they showed a great interest and strong support with overall consensus that BIER will build a right foundation for efficient multicast delivery for operators to standardize. I promoted BIER within Thomson Reuters on the Business and Technology sides and feedback was overwhelming, with huge interest from Thomson Reuters development community. Based on my involvement with BIER, I struggle to define it as Experimental as per included definition below and I completely agree with Stewart on his assessment of your proposed charter. Please don't take it as a criticism, I am very novice in terms of IETF protocols and procedures but as per my findings of IETF definitions:

"WG charters state the scope of work for group, and lay out goals and milestones that show how this work will be completed."

The proposed version in the way it was written more focusing on conditional statements and depicts some unwillingness of IETF to promote/proceed with BIER as a committed work.

Snapshot from IETF.org

“4.2.1 Experimental

The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution.”

I would like to continue to promote BIER and take an active part in developing of new multicast technologies for my company and industry benefits. There are plenty of challenges in this arena, but only via active participation these challenges can be resolved. We need to see commitment from IETF to move BIER development forward.

Regards,

Arkadiy

From: BIER [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Thursday, February 12, 2015 10:14 AM
To: stbryant
Cc: Adrian Farrel; [email-masked]; [email-masked]; Alvaro Retana
Subject: Re: [Bier] proposed BIER charter

Stewart,

I certainly appreciate your taking the time to provide feedback.  I understand that you
are excited by this technology and have urged that innovation needs time and space
to be worked on before being evaluated by the harsh realities of the marketplace and
interest in deployments.

On Thu, Feb 12, 2015 at 8:44 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:
Alia

At this time, a sufficiently compelling case has not been made to convince that
PS is anywhere near appropriate for this change of adding a completely new forwarding
algorithm and a fourth  encapsulation to go with IPv4, IPv6, and MPLS to the Internet
architecture for the next 15+ years.

It is true that if that changes between now and when drafts are ready to progress, that can
be revisited.

There are WGs that have been chartered to do experimental work in the past.  I understand
that it is disappointing that there wasn't a strong case for more than experimental at this time.

I have been extremely clear since the last IETF that I was only considering Experimental for
the WG for the initial chartering.

The technology needs to work in both locations - given the use-cases.  What specifically are
you objecting to?

By creating a WG for open collaboration and defining an ambitious new forwarding technology,
the IETF is not embracing and encouraging innovation?  I suppose it's all in the eye of the
beholder - but to me it feels like "give an inch and get pushed for a mile".

IF the encapsulations are specified in a way that two independent interoperable implementations
are not available, it both increases the risk that we might end up with two different versions - one
Experimental and another through bitter experience that is PS later - and is a poor indication of
the lack of industry support and interest in the technology and its use.

Regards,
Alia

- Stewart

WG Chairs:

Regards,
Alia

BIER mailing list

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

--

---

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Feb 2015 19:29:23 -0500

Hi Arkadiy,

First, we were all new to the IETF once.  Your feedback and opinions are
quite welcome.  WG charters are discussed to get feedback and agreement on
the details and scope.

I'm delighted to hear of your interest and that of other operators.  I did,
of course, speak with you before the BoF and know of your involvement in
the drafts.  Unfortunately, I haven't heard such support expressed in the
IETF by operators; obviously vendors' interest
can reflect such interest indirectly.

I believe that BIER is currently at the stage of a development effort.  I
have done my best to be clear that there is a path forward from
Experimental - but it really really depends on getting some experience with
the technology and being more confident of the actual demand.

I am trying to provide a WG to get rapid progress on BIER.  The other
option is to wait and do a second BoF possibly in March or in July and see
if there is stronger demand for having the technology and really clear
benefits articulated that would drive it.  Unfortunately, while the
problem-statement and use-cases have improved since the Nov BoF, they are
still not sufficiently convincing.

This is very ambitious innovative work - which is great - but I have seen
many technologies be the excitement of the year and then flounder.
If it does catch on, then there is certainly an ability to recharter to the
standards track.  As you probably noticed, in the proposed charter, there
is a item 9, in which your help could be particlarly significant.

Regards,
Alia

On Thu, Feb 12, 2015 at 6:20 PM, <[email-masked]> wrote:

>  Alia,
>
> I have been engaged with BIER technology for the last year and a half from
> its inception. It come along way and it was not driven just based on
> excitement. This work is backed up by commitment from major vendors and
> multiple operators. I have discussed BIER on multiple occasions with other
> operators, they showed a great interest and strong support with overall
> consensus that BIER will build a right foundation for efficient multicast
> delivery for operators to standardize. I promoted BIER within Thomson
> Reuters on the Business and Technology sides and feedback was overwhelming,
> with huge interest from Thomson Reuters development community. Based on my
> involvement with BIER, I struggle to define it as Experimental as per
> included definition below and I completely agree with Stewart on his
> assessment of your proposed charter. Please don't take it as a criticism, I
> am very novice in terms of IETF protocols and procedures but as per my
> findings of IETF definitions:
>
> "WG charters state the scope of work for group, and lay out goals and
> milestones that show how this work will be completed."
>
> The proposed version in the way it was written more focusing on
> conditional statements and depicts some unwillingness of IETF to
> promote/proceed with BIER as a committed work.
>
>
>
> Snapshot from IETF.org
>
> “4.2.1 Experimental
>
> The "Experimental" designation typically denotes a specification that is
> part of some research or development effort. Such a specification is
> published for the general information of the Internet technical community
> and as an archival record of the work, subject only to editorial
> considerations and to verification that there has been adequate
> coordination with the standards process (see below). An Experimental
> specification may be the output of an organized Internet research effort
> (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be
> an individual contribution.”
>
>
>
> I would like to continue to promote BIER and take an active part in
> developing of new multicast technologies for my company and industry
> benefits. There are plenty of challenges in this arena, but only via active
> participation these challenges can be resolved. We need to see commitment
> from IETF to move BIER development forward.
>
>
>
> Regards,
>
> Arkadiy
>
>
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Alia Atlas
> *Sent:* Thursday, February 12, 2015 10:14 AM
> *To:* stbryant
> *Cc:* Adrian Farrel; [email-masked]; [email-masked]; Alvaro Retana
> *Subject:* Re: [Bier] proposed BIER charter
>
>
>
> Stewart,
>
>
>
> intent of pushing for it to be chartered before the Dallas IETF.  This has
> not yet gone through IESG review and it may have some aspects updated.
>
>
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Feb 2015 02:46:00 +0000

Hi Alia,

I fully agree with your point that requirements are essential for designing any new data-plane encapsulation. I wonder whether the BIER WG would still work out a data-plane requirement document given the architecture document has already been there. IMHO, Those fields/elements on the data-plane which are essential for the BIER forwarding could be specified either in the architecture document or in the data-plane requirement document. As such, both the generic BIER encapsulation scheme and the MPLS-dependant BIER encapsulation scheme should respect those data-plane requirements. In other words, those necessary fields/elements for BIER forwarding could be completely contained in a generic BIER header or spread over the MPLS header and the MPLS-dependant  BIER header. With those data-plane requirements which are independent from any specific encapsulation scheme, we could further evaluate the pros and cons of each scheme.

Best regards,
Xiaohu

From: Alia Atlas [mailto:[email-masked]]
Sent: Thursday, February 12, 2015 10:51 PM
To: Xuxiaohu
Cc: Antoni Przygienda; [email-masked]
Subject: Re: [Bier] proposed BIER charter

Xiaohu,

I certainly understand that you are very interested in working on a generic encapsulation for BIER.  I do think this may be useful work.  The MPLS encapsulation work is further along and has significant benefits in terms of not needing to revisit a number of issues that MPLS already handles.

Your proposed changes basically eliminate any indication of what needs to be considered in the generic encapsulation, without any reasoning, and pushes for it to be considered as an equal focus with the MPLS encapsulation.  I am already concerned that there's a lot of work for bier to get through.

Do you think that the requirements on the generic encapsulation need refining and why?

Regards,
Alia

On Thu, Feb 12, 2015 at 4:28 AM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tony,

OLD:

Best regards,
Xiaohu

From: Antoni Przygienda [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, February 12, 2015 2:27 PM
To: Xuxiaohu; [email-masked]<mailto:[email-masked]>
Subject: RE: [Bier] proposed BIER charter

<hat type=”wg chair”>

</hat>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Feb 2015 21:57:59 -0500

Hi Xiaohu,

The details of what fields and sizes need to be in the encapsulation should
be captured in the architecture draft.
In the proposed charter, that is specified in:
"   1) BIER architecture: The WG will publish an architecture, based
   upon draft-wijnands-bier-architecture-04.  It will include the
   normative algorithm for how BIER packet forwarding is done.  It
   will specify the information that is required by a BIER header to
   support BIER forwarding."

As you can probably tell from this charter, I am really steering away from
process-style documents in favor
of combining requirements with the associated solutions, in terms of
minimizing the number of use-case drafts,
and so on.  At the end of the day, we need RFCs that describe functionality
that can be implemented, deployed,
and be interoperable.

Regards,
Alia

On Thu, Feb 12, 2015 at 9:46 PM, Xuxiaohu <[email-masked]> wrote:

>  Hi Alia,
>
>
>
> I fully agree with your point that requirements are essential for
> designing any new data-plane encapsulation. I wonder whether the BIER WG
> would still work out a data-plane requirement document given the
> architecture document has already been there. IMHO, Those fields/elements
> on the data-plane which are essential for the BIER forwarding could be
> specified either in the architecture document or in the data-plane
> requirement document. As such, both the generic BIER encapsulation scheme
> and the MPLS-dependant BIER encapsulation scheme should respect those
> data-plane requirements. In other words, those necessary fields/elements
> for BIER forwarding could be completely contained in a generic BIER header
> or spread over the MPLS header and the MPLS-dependant  BIER header. With
> those data-plane requirements which are independent from any specific
> encapsulation scheme, we could further evaluate the pros and cons of each
> scheme.
>
>
>
> Best regards,
>
> Xiaohu
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Thursday, February 12, 2015 10:51 PM
> *To:* Xuxiaohu
> *Cc:* Antoni Przygienda; [email-masked]
> I certainly understand that you are very interested in working on a
> generic encapsulation for BIER.  I do think this may be useful work.  The
> MPLS encapsulation work is further along and has significant benefits in
> terms of not needing to revisit a number of issues that MPLS already
> handles.
>
>
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Feb 2015 02:58:41 +0000

s/those necessary fields/elements for BIER forwarding could be completely contained in a generic BIER header or spread over the MPLS header and the MPLS-dependant  BIER header
/ those necessary fields/elements for BIER forwarding could be completely contained in a generic BIER header or spread over the MPLS header (e.g., TTL and CoS) and the MPLS-dependant  BIER header and even be indirectly figured out through the MPLS lookup.

Best regards,
Xiaohu

From: Xuxiaohu
Sent: Friday, February 13, 2015 10:46 AM
To: 'Alia Atlas'
Cc: Antoni Przygienda; [email-masked]
Subject: RE: [Bier] proposed BIER charter

Hi Alia,

Best regards,
Xiaohu

From: Alia Atlas [mailto:[email-masked]]
Sent: Thursday, February 12, 2015 10:51 PM
To: Xuxiaohu
Cc: Antoni Przygienda; [email-masked]<mailto:[email-masked]>
Subject: Re: [Bier] proposed BIER charter

Xiaohu,

Regards,
Alia

OLD:

Best regards,
Xiaohu

<hat type=”wg chair”>

</hat>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Feb 2015 03:14:17 +0000

Hi Alia,

I like your approach of steering away from process-style documents. It’s an efficient way. Hence, the generic BIER encapsulation doc and the MPLS-dependant BIER encapsulation doc need to follow the architecture doc. That’s to say, any functionality required for the BIER forwarding as specified in the architecture doc should be supported by each encapsulation scheme.

Best regards,
Xiaohu

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, February 13, 2015 10:58 AM
To: Xuxiaohu
Cc: Antoni Przygienda; [email-masked]
Subject: Re: [Bier] proposed BIER charter

Hi Xiaohu,

The details of what fields and sizes need to be in the encapsulation should be captured in the architecture draft.

As you can probably tell from this charter, I am really steering away from process-style documents in favor
of combining requirements with the associated solutions, in terms of minimizing the number of use-case drafts,
and so on.  At the end of the day, we need RFCs that describe functionality that can be implemented, deployed,
and be interoperable.

Regards,
Alia

On Thu, Feb 12, 2015 at 9:46 PM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Best regards,
Xiaohu

From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, February 12, 2015 10:51 PM
To: Xuxiaohu
Cc: Antoni Przygienda; [email-masked]<mailto:[email-masked]>
Subject: Re: [Bier] proposed BIER charter

Xiaohu,

Regards,
Alia

OLD:

Best regards,
Xiaohu

<hat type=”wg chair”>

</hat>

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 14 Feb 2015 01:38:27 +0000

<hat type="wg-chair">

Stewart, I concur with Alia that a new data plane concept like this one is a thing seldom introduced and frail with surprising risks (IPv6 = ~15 years from idea to reasonable scale of deployment ? MPLS = ~ 10 years ? ;-)

IMO, it is far less risky to give this thing a vibrant WG where people know that they have to push for serious implementations (and prove them viable before standards track with resulting huge investment in silicon by many companies will be taken) rather than rush it without adequate experience and end up with a massive egg on our collective faces.  The path to standards is fair (FYI, it was initially much stricter) and clearly spelled out me thinks. I'm waiting for people getting excited by the fame attached to a first Linux kernel implementation going @ 1GB bitrate (I'm too smart to talk about packet size or bitstring lengths here ;-)

Pen-ultimately, I would like to see precise use-cases for the low link-speeds and edge to consider this further. A 'may be useful' does not justify major surgery on charter IMO.

Ultimately, early vendor support & strong customer response in the market place is the best pressure point for IETF to move such work into Standards Track lest they end up looking like Johnie-come-laties. We ain't there yet.

</hat>

--- tony

From: BIER [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, February 12, 2015 5:45 AM
To: Alia Atlas; [email-masked]
Cc: Adrian Farrel; [email-masked]; Alvaro Retana
Subject: Re: [Bier] proposed BIER charter

Alia

- Stewart

WG Chairs:

Regards,
Alia

BIER mailing list

--

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sat, 14 Feb 2015 08:38:50 +0100

Hi Alia,

> I'm delighted to hear of your interest and that of other operators.  I did, of course, speak with you before the BoF and know of your involvement in the drafts.  Unfortunately, I haven't heard such support expressed in the IETF by operators; obviously vendors’ interest can reflect such interest indirectly.

I would just like to point out that we have 4 different operators in our contributing author section of the BIER architecture draft (https://tools.ietf.org/html/draft-wijnands-bier-architecture-04#section-10) that indicated they want to help move this work forward, you don’t consider that as ‘support’?

Thx,

Ice.

---

From: Alia Atlas <[email-masked]>
Date: Sat, 14 Feb 2015 09:33:12 -0500

Ice,

On Sat, Feb 14, 2015 at 2:38 AM, IJsbrand Wijnands <[email-masked]> wrote:

> Hi Alia,
>
> > I'm delighted to hear of your interest and that of other operators.  I
> did, of course, speak with you before the BoF and know of your involvement
> in the drafts.  Unfortunately, I haven't heard such support expressed in
> the IETF by operators; obviously vendors’ interest can reflect such
> interest indirectly.
>
> I would just like to point out that we have 4 different operators in our
> contributing author section of the BIER architecture draft (
> https://tools.ietf.org/html/draft-wijnands-bier-architecture-04#section-10)
> that indicated they want to help move this work forward, you don’t consider
> that as ‘support’?
>

Obviously, have active authors implies that they are interested in
developing the technology because it has promise.  Obviously, by being
willing to charter a working group, I have heard and agree.   Except for
Arkadiy, they haven't participated on the mailing list or spoke up at the
BoF at all - despite all being active IETFers.

Regards,
Alia

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 14 Feb 2015 08:35:34 -0800

Alia, Arkadiy is the user, operator, and requirement setter. He will use the technology. And he has done more than speak up, he is a ℅-author and helping to build the technology to be useful and practical. 

Dino

> On Feb 14, 2015, at 6:33 AM, Alia Atlas <[email-masked]> wrote:
> 
> Ice,
> 
> Obviously, have active authors implies that they are interested in developing the technology because it has promise.  Obviously, by being willing to charter a working group, I have heard and agree.   Except for Arkadiy, they haven't participated on the mailing list or spoke up at the BoF at all - despite all being active IETFers.  
> 
> Regards,
> Alia
>  
>> Thx,
>> 
>> Ice.
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sat, 14 Feb 2015 21:13:38 +0100

Alia,

> Obviously, have active authors implies that they are interested in developing the technology because it has promise.  Obviously, by being willing to charter a working group, I have heard and agree.   Except for Arkadiy, they haven't participated on the mailing 

You’re doing a very good job in hiding your excitement ;-) 

> list or spoke up at the BoF at all - despite all being active IETFers. 

First of all, at least 3 of the operators where not in Hawaii. Second, you have your priorities reversed! You should put much more weight in operators that are willing to associate their name with a draft and help move the technology forward. Anybody can go to the mic at an IETF meeting and make some comments. Its the people on the drafts that make the difference and GSD.

Thx,

Ice.

---

From: Brian Haberman <[email-masked]>
Date: Sat, 14 Feb 2015 15:37:20 -0500

Hi Stewart,

> breadth of implementation and implementation experience.

Given that we do not have a wealth of deployment experience with BIER, I
think it is quite reasonable to start the process as an Experimental
specification.  Part of the reason for me holding this view is that
there is still some areas of work needed to understand how BIER will fit
in the overall multicast architecture.  For example, in non-MPLS
deployments, there is a need to specify how BIER-battered forwarding
will interact with the group management protocols.

> it my also be deployed at the edge where a much lower threshold

I agree, but an Experimental specification does not preclude such cases.
 In fact, those deployments will help all of us understand what
deficiencies or efficiencies are in BIER.

> and encouraging innovation.

I disagree with the above view.  The label placed on specifications
rarely slows down technology if it is viable.

Regards,
Brian

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 15 Feb 2015 01:00:29 +0000

specification.

We may find the above a bit odd, if we relate to how RFC3031/3032 (MPLS architecture and encoding) were put on standards track right from the getgo, despite having limited deployment experience with MPLS.

Experimental in many circles play a significant mind-barrier game.

Part of the reason for me holding this view is that
there is still some areas of work needed to understand how BIER will fit
in the overall multicast architecture.

Ummmm....we will certainly have work to do in not only understanding existing areas, but also exploring new areas (such as 6lopan) for BIER. But that's cant/mustn't be the reason to classify any work as experimental.

Cheers,
Rajiv

On Feb 14, 2015, at 3:37 PM, Brian Haberman <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stewart,

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Sun, 15 Feb 2015 11:37:36 -0500

Hi Rajiv,

On 2/14/15 8:00 PM, Rajiv Asati (rajiva) wrote:
> Given that we do not have a wealth of deployment experience with
> BIER, I think it is quite reasonable to start the process as an
> Experimental specification.
> 
> We may find the above a bit odd, if we relate to how RFC3031/3032
> (MPLS architecture and encoding) were put on standards track right
> from the getgo, despite having limited deployment experience with
> MPLS.

I am speaking to this from the multicast perspective.

> Experimental in many circles play a significant mind-barrier game.

I am not aware of those situations, but I am not involved in MPLS
circles.  Can someone describe such a scenario?

> 
> Part of the reason for me holding this view is that there is still
> some areas of work needed to understand how BIER will fit in the
> overall multicast architecture.
> 
> Ummmm....we will certainly have work to do in not only understanding
> existing areas, but also exploring new areas (such as 6lopan) for
> BIER. But that's cant/mustn't be the reason to classify any work as
> experimental.
> 

As I stated above, I am looking at this from the multicast (i.e., IP)
perspective.  It took quite a few years before the community felt
comfortable moving PIM from Experimental to Standards Track.

It is quite possible that the MPLS-centric components of BIER are viewed
much differently than the IP-centric components.

Regards,
Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 15 Feb 2015 14:42:48 -0500

Having been the routing AD who chartered the MPLS work in the first 
place, there was already significant deplopyment of something similar, 
and an understanding that the deployment might have to change.  There 
were also many op[erators who were asking for the technology.  And it 
was a natural evolution and replacement of an existing technology.

Yours,
Joel

PS: We still made mistakes.  The mess with CRLDP and RSVP-TE should have 
resulted, in my opinion, in the working group picking one or both ending 
up on experimental.  Fortunately, that was pure control plane.  And we 
did later pick one.

On 2/14/15 8:00 PM, Rajiv Asati (rajiva) wrote:
> We may find the above a bit odd, if we relate to how RFC3031/3032 (MPLS
> architecture and encoding) were put on standards track right from the
> getgo, despite having limited deployment experience with MPLS.
>
...

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Feb 2015 11:38:15 +0000

> circles.  Can someone describe such a scenario?
Firstly experimental implies in most peoples mind "might not work".
Secondly we tell everyone that experimental codepoints MUST NOT
be deployed in production. There is a very real risk of the conflation
of these two  points into "this experimental RFC is on that may not
work and must not be deployed in a production network".

If you go back to my original point, I was saying that I thought that
dictating the track at this stage was premature and that the
decision should be made when documents were ready, and thus
when more information was available.

> comfortable moving PIM from Experimental to Standards Track.
The key difference between this multicast technology and earlier
such technologies is that classic m/c distributes client state
through-out the network, which frankly does not scale, whereas
this is a technology in which the client state is shared solely with
the information distributor, which is intrinsically more scalable.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Feb 2015 13:57:32 +0000

On 12/02/2015 15:13, Alia Atlas wrote:
> interest in deployment.
I think my three key points were:

a) We should not prejudge the technology at this stage, but rather should
take a contingency approach, i.e. make a decision when we need to make
it and have more information, rather than make it now and risk either
creating a self fulfilling prophecy, or needing to revisit this decision
later with all the associated work.

b) Listen to what David Ward was saying in his talk in Hawaii about the
risk of the IETF becoming irrelevant in the face of the speed of open 
source.
In this case we seem to be putting up barriers to speed of execution
rather than breaking them down.

c) Do not pre-judge how a technology of this type will be implemented
given the re-balancing we are seeing between s/w and h/w, i.e. do not
express a view on implementation technology in a charter. In the version
of the charter I reviewed you explicitly called for a h/w implementation.

> architecture for the next 15+ years.
At this time we have no evidence either way, so why make
a statement at all, why not gather the evidence as we do the
engineering?

In one of the cases (BEIR/MPLS) it is not clear that this is an extension
beyond the norm. Certainly it  seems nothing worse than VXLAN
which is headed to be a de-facto standard.

> The technology needs to work in both locations - given the use-cases.  
The edge case will surely be operating in an environment where
s/w forwarding is in ascendency and thus may just be another
NFV function. My concern is that you were asserting a h/w forwarding
paradigm which is not the current industry trajectory for the edge.

> beholder - but to me it feels like "give an inch and get pushed for a 
I object to that statement which seems to me to be contra to the IETF
ethos of community consensus.

> the lack of industry support and interest in the technology and its use.
"IF the encapsulations are specified in a way that two independent 
interoperable implementations
are not available, " Does not parse.

The specification needs to be implementation agnostic and compatible 
with any
reasonable implementations platform: h/w, f/w, s/w. Now you could perhaps
assert that you need one of each style, but that was not what you 
proposed, you
proposed h/w.

- Stewart

>>     I have been working on getting a charter together for BIER with
>>     the intent of pushing for it to be chartered before the Dallas
>>     IETF.  This has not yet gone through IESG review and it may have
>>     some aspects updated.
>>
>>     [email-masked]  <mailto:[email-masked]>

---

From: Brian Haberman <[email-masked]>
Date: Tue, 17 Feb 2015 10:10:42 -0500

Hi Stewart,

> work and must not be deployed in a production network".

Maybe your experience is radically different than mine, but most people
I have interacted with about RFCs outside of the IETF have zero clue
about the Experimental/Standards Track/Informational labels.  I am more
than willing to believe that there are people who pay attention to those.

The issue with code points is quite valid.  However, depending on the
registry in question, permanent allocations can be made for
Experimental/Informational track documents.

I will point out that PIM was labeled Experimental for quite some time
and saw significant deployment in production networks.

> when more information was available.

And I will just re-iterate that I am just speaking as an individual who
has a history in the multicast (is it experimental or is it not) domain.
 It is up to the consensus of the community as to what goes into the
charter.

> the information distributor, which is intrinsically more scalable.

In some of the proposed scenarios, there will be significant work needed
to get the client state to the distributor.

But let me state this one more time, I am just an individual in this
community.  I have no problem with being ruled in the rough.

Regards,
Brian

---

From: Alia Atlas <[email-masked]>
Date: Tue, 17 Feb 2015 10:56:41 -0500

Ice,

On Sat, Feb 14, 2015 at 3:13 PM, IJsbrand Wijnands <[email-masked]> wrote:

> Arkadiy, they haven't participated on the mailing
>

Shall I bounce up and down and talk enthusiastically?  This is the option
that gets a WG created quickly and has a fast path for getting the work
done.  This is the option that says "hey, this is neat work and a really
cool idea.  Let's get it fleshed out and see if there's actual interest in
deployment".   It's a architecturally clever idea but I'm twitchy about the
forwarding plane implications - particularly for the non-MPLS encapsulation.

> First of all, at least 3 of the operators where not in Hawaii. Second, you
> have your priorities reversed! You should put much more weight in operators
> that are willing to associate their name with a draft and help move the
> technology forward. Anybody can go to the mic at an IETF meeting and make
> some comments. Its the people on the drafts that make the difference and
> GSD.
>

Without being inside a team of authors working on a draft - and when a
draft has 5 authors/editors and 8  more contributing authors, it's quite
hard to tell how much enthusiasm and work is being put in, much less the
difference between "neat idea - let's explore it" and "this needs to be in
my network ASAP".

Regards,
Alia

---

From: Luay Jalil <[email-masked]>
Date: Fri, 20 Feb 2015 04:38:53 -0600

This technology is interesting and I'd like to see it progress

Thanks,
Luay
On Feb 17, 2015 9:59 AM, "Alia Atlas" <[email-masked]> wrote:

>> First of all, at least 3 of the operators where not in Hawaii. Second,
>> you have your priorities reversed! You should put much more weight in
>> operators that are willing to associate their name with a draft and help
>> move the technology forward. Anybody can go to the mic at an IETF meeting
>> and make some comments. Its the people on the drafts that make the
>> difference and GSD.
>>
>